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SECTION  I 


INTRODUCTION 


A.  OVERVIEW  AND  BACKGROUND 

Systems  Technology,  Inc.  (STI)  contracted  with  DARPA  to  develop  a 
low-cost  device  for  training  pilots  in  the  use  of  the  F-16  Head-Up  Dis¬ 
play  (HUD).  The  HUD  and  associated  subsystems  are  dominant  features  of 
the  F-16's  instrument  panel,  and  are  designed  to  be  the  pilot's  primary 
aid  in  flight,  weapon  system  energy  management.  In  this  role  the  HUD  is 
an  extremely  versatile  instrument,  but  by  the  same  token  is  also  quite 
complicated  to  use.  Its  three  mode  categories  of  flight  management, 
ground  attack  and  air  combat  include  eleven  different  display  formats 
with  a  bewildering  repertoire  of  symbology.  Training  pilots  to  master 
the  various  HUD  modes  is  the  key  to  optimizing  the  F-16's  deployment  as 
an  effective  air  superiority  fighter. 

B.  THE  PROBLEM 

Air  Force  experience  indicates  that  pilot  trainees  do  not  always 
receive  enough  flight  time  to  learn  the  use  of  all  the  HUD  display  for¬ 
mats.  A  brief  overview  of  the  HUD  system  and  its  capabilities  reveals 
the  magnitude  of  the  problem.  An  F-16  cockpit  layout  is  shown  in 
Fig.  1.  HUD  symbology  is  generally  determined  by  selecting  a  mode  via 
the  stores  control  panel  (SCP)  shown  in  Fig.  1.  HUD  symbology  can  addi¬ 
tionally  be  influenced  by  activating  controls  on  the  side  stick  and 
throttle  handles,  and  the  HUD  control  panel  below  the  HUD  display. 
Given  the  large  number  of  display  modes,  and  additional  variations  pro¬ 
duced  by  optional  control  inputs,  it  is  not  surprising  that  a  signifi¬ 
cant  training  problem  exists. 

Documentation  also  compounds  the  training  problem.  Procedures  for 
the  Navigation,  Air-to-Air  Combat  and  Air-to-Surface  Attack  modes  are 
described  in  three  documents,  i.  e.  ,  Refs.  1-3.  These  three  documents 
must  be  carefully  read  and  compared  to  gain  a  complete  picture  of  the 
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HUD  mode  weapons  delivery  procedures,  display  options  and  energy  manage¬ 
ment  capabilities  available  to  the  F-16  pilot.  Thus  the  overall  train¬ 
ing  problem  seems  to  result  from  a  combination  of  complex  procedures,  a 
profusion  of  options  and  formats,  and  obscure  and  scattered  documenta¬ 
tion. 

C.  APPROACH  AND  SUMMARY 

Based  on  successful  experience  with  previous  low-cost  training 
devices,  DARPA  seeks  to  provide  equipment  that  is  highly  motivating  to 
operate  and  requires  minimal  support  or  training  in  its  operation,  much 
as  is  the  case  with  commercial  video  games.  The  general  approach  taken 
here  to  accomplish  the  above  objective  was  to  configure  a  system  with 
low-cost,  commercial  microcomputer  and  video  hardware,  and  minimize  any 
special-purpose  hardware  buildup.  With  this  approach  the  functional 
requirements  for  the  HUD  tasks  could  be  achieved  primarily  through  soft¬ 
ware  development.  This  approach  also  had  the  advantage  of  allowing  easy 
modification  or  additions  in  the  future  to  handle  F-16  modifications 
and/or  new  training  requirements. 

Because  of  various  development  problems  encountered  during  the  pro¬ 
ject,  it  was  not  possible  to  complete  hardware  and  software  development 
with  the  available  funds.  Significant  technical  advancements  were 
achieved  in  low-cost  display  technology,  however,  and  valuable  experi¬ 
ence  was  gained  that  can  be  applied  to  future  low-cost  simulator  devel¬ 
opments.  The  nature  of  these  developments  will  be  discussed  in  the 
remainder  of  the  report  along  with  implications  for  using  state-of-the- 
art  technology  in  future  low-cost  simulator  equipment.  In  Section  II, 
the  functional  design  and  planned  physical  layout  for  the  simulator  are 
discussed.  Visual  display  developments  are  discussed  in  Section  III 
beginning  with  a  review  of  current  state-of-the-art  low-cost  technology, 
and  Including  a  discussion  of  functional  requirements  for  display  pro¬ 
cessing.  Supporting  details  on  display  requirements  are  given  in  Appen¬ 
dices  A  and  B.  Supporting  details  on  display  advancements  achieved  in 
this  project  are  given  in  Appendix  C.  Host  processor  considerations 
including  dynamic  computations  are  reviewed  in  Section  IV.  Finally,  a 
technology  summary  and  potential  future  advancements  are  summarized  in 
Section  V. 


SECTION  II 

FUNCTIONAL  DESIGN  AND  PHYSICAL  LAYOUT 

A.  OVERVIEW 

As  part  of  the  functional  design  effort,  the  pilot's  usage  of  the 
F-16  HUD  during  typical  flight  maneuvers  was  reviewed  in  some  detail  in 
order  to  better  define  the  required  training  hardware  and  procedures. 
As  part  of  this  review  we  also  visited  personnel  at  Wright  Patterson 
AFB,  Edwards  AFB,  Luke  AFB,  and  Williams  AFB  to  discuss  procedures,  and 
observe  actual  F-16  hardware  and  an  F-16  simulation.  It  was  generally 
concluded  that  the  HUD-related  tasks  are  complex  and  not  clearly  docu¬ 
mented.  The  simulation  group  at  Williams  further  pointed  out  that  an 
enormous  amount  of  work  was  required  in  setting  up  just  the  air-to- 
ground  mode  requirements  for  their  simulation,  in  spite  of  the  fact  that 
they  are  working  with  an  actual  F-16  HUD. 

The  above  state  of  affairs  left  us  in  much  the  same  dilemma  as  F-16 
pilots  and  the  Williams  AFB  simulation  group,  i. e.  ,  a  very  complex  sys¬ 
tem  to  learn  with  marginal  resources  to  accomplish  the  task.  This  situ¬ 
ation  was  recognized  early  on,  so  the  following  ground  rules  were  set  up 
to  allow  a  versatile  training  device  to  be  built  without  expending 
excessive  work  on  superfluous  details  of  system  definition: 

•  The  hardware  configuration  would  be  comprehensive 
enough  to  mechanize  all  HUD  tasks. 

•  The  computer  software  structure  would  also  be 
comprehensive  enough  to  handle  all  tasks. 

•  One  air-to-ground  and  one  air-to-air  scenario 
would  be  selected  as  representative  of  the  F-16's 
primary  attack  modes. 

The  air-to-ground  and  air-to-air  tasks  selected  for  mechanization 
are  illustrated  in  Figs.  2  and  3,  respectively.  The  hardware  require¬ 
ments  for  the  air-to-surf ace  and  air-to-air  weapon  delivery  modes  are 
shown  in  Figs.  2a  and  3a.  Because  of  basic  limitations  imposed  by  a  low 


Figure  2a.  Air-to-Surface  Weapon  Delivery  mode  Selection/Display 


TIME  TO  GO 


P2V 

fl-C 
n  5  T  L 
UT05 


4' 


BUJhBB 
Tnnh 
PR  I  P 
SOFT 
V  f 


PREDESIGNATE 


1.  LOCATE  TGT.  INITIATE 
^ .  MODE.  ROiL  INTO  OIVE 


3.  FLY  AIRCRAFT  TO  PLACE 
FPM  ON  STEERING  LINE. 


STEERPOINT  SYMBOL 
TARGET  DESIGNATOR 
BOX  AND  FLIGHT  PATH 
MARKER 

PULL  UP  ANTICIPATION 
CUE 

RADAR  RANGE 
^  DIVE  TOSS  MODE 


,2.  STEER  AIRCRAFT  TO  PLACE 
TARGET  DESIGNATOR  BOX  ON 
TARGET  AND  DEPRESS  AND 
HOLD  WPN  REL  BUTTON.  IF 
REQUIRED.  USE  CURSOR  CONTROL 
TO  REFINE  TARGET  DESIGNATOR 
BOX  POSITION 


•RE-ATTACK-  TARGET  DESIGNATOR 
WILL  REMAIN  OVER  TARGET  UNTIL  MODE 
EXIT. 

•  RE  INITIALIZATION-  TARGET 
DESIGNATOR  WILL  RETURN  TO  FPM 
WHEN  DESIGNATE  IS  DEPRESSED 


4.  SOLUTION  CUE  APPEARS 
WHEN  DESIGNATED  TARGET 
'  AT  MAX  TOSS  RANGE 


5.  WPN  REL  BUTTON  DEPRESSED 
'  TO  PROVIDE  RELEASE  CONSENT 


TOSS  \ 
DELIVERY  \ 
OPTION  \ 


LESS  CD 
POST-DESIGNATE 


LEVEL 

DELIVERY 

OPTION 


>  w 


CD 

POST-DESIGNATE 


STEERING  LINE 

LEVEL  TOSS  CUE 
SOLUTION  CUE 

FLIGHT  PATH  MARKER 

PULL-UP  ANTICIPATION 
CUE 

- TIME  TO  GO 

'  BEARING  AND 
RANGE  TO  TARGET 


*  ‘  4  -HO 


6.  LEVEL  CUE 
APPEARS  WHEN 
4-g  PULLUP  WILL 
RESULT  IN  LEVEL 
DELIVERY 


DISTANCE  TO  OEST. 
AND  DEST.  NO. 


TARGET  DESIGNATOR 
BOX 


DTOS  MODE 

Figure1.  2b.  Dive  Toss  Task  Description 


TR-1201-1 


37*3 


*** 

4 


Figure  3a.  Air-to-Air  Weapon  Delivery  Mode  Selection/Displays 
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Figure  3b.  Missile  Override  Task  Description 
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cost  "desk  top"  physical  configuration  (discussed  further  on)  we  planned 
not  to  implement  the  starred  components  in  Figs.  2a  and  3a.  These  ele¬ 
ments,  according  to  EAFB  and  WAFB  personnel,  are  somewhat  peripheral  to 
the  primary  modes  in  which  the  HUD  is  normally  used.  A  key  element  in 
HUD  operation  is  the  stores  control  panel  (SCP)  which  was  added  to  the 
system  that  was  originally  proposed.  A  future  option  for  the  trainer 
could  include  a  "sit-down"  mockup  (discussed  further  on)  which  could 
easily  accommodate  the  starred  items  in  Figs.  2a  and  3a. 

B.  FUNCTIONAL  DESIGN 

An  overall  block  diagram  of  major  functional  elements  of  a  proposed 
F-16  HUD  trainer  is  illustrated  in  Fig.  4.  The  various  functions  in 
Firg.  4  were  planned  to  be  mechanized  with  a  combination  of  hardware  and 
software.  The  objective  of  the  functional  design  was  to  reflect  DARPA 
and  implicit  Air  Force  requirements  in  achieving  the  stated  objective: 
a  low-cost,  highly  motivational  F-16  HUD  Training  device. 

Overall  control  of  simulator  operation  in  Fig.  4  is  provided  by  the 
Simulator  Control  Module  (SCM).  This  module  exerts  supervisory  control 
over  general  simulator  operations,  based  on  simple  menu-driven  responses 
from  the  pilot.  The  SCM  should  provide  structured  instructions  and  mode 
options  to  the  pilot  allowing  him  to  choose  from  appropriate  HUD  modes. 
Scenarios  for  the  various  HUD  modes  (i.e. ,  navigation,  ground  attack, 
air  combat)  should  be  initiated  and  controlled  by  the  SCM,  via  pilot 
commands  received  through  the  Stores  Control  Panel  (SCP). 

Scoring  and  feedback,  the  keys  to  motivating  pilot  participation, 
were  also  to  be  controlled  by  the  SCM.  Given  various  control  task  per¬ 
formance  measures  (e. g.  ,  tracking  error,  target  hits,  pullup  or  breakoff 
timing)  the  SCM  could  generate  a  composite  score  that  rewards  good  per¬ 
formance  and  penalizes  bad  performance,  which  is  then  fed  back  to  the 
pilot  via  visual  and  auditory  displays.  The  details  of  the  visuals  can 
be  structured  so  as  to  maximize  the  motivational  impact  of  scoring. 
Similar  approaches  have  been  implemented  in  driving  simulator  research 
and  have  achieved  a  high  degree  of  motiviation  among  test  subjects 


The  most  critical  portion  of  the  functional  design  is  the  real  time 
manual  control  loop  shown  in  more  detail  in  Fig.  5.  In  order  to  achieve 
realistic  control  dynamics,  excessive  computational  delays  must  be 
avoided.  Most  critical  is  the  control  of  aircraft  attitude  (pitch  and 
roll  on  the  HUD  attitude  bars  and  the  out  of  window  real  world  scene) 
and  fire  control  symbols  relative  to  targets.  This  "inner-loop"  control 
must  be  updated  at  20  Hz  or  faster  to  avoid  unnatural  control  delay  dif¬ 
ficulties.  The  HUD  symbology  must  also  be  presented  with  smooth  appar¬ 
ent  motion  and  without  noticeable  flicker.  A  refresh  rate  of  at  least 
40  Hz  will  be  required  to  achieve  these  objectives.  Hardware  and  soft¬ 
ware  selections  for  achieving  these  requirements  are  discussed  below. 
Further  detailed  discussion  of  visual  display  requirements  is  given  in 
Appendices  A  and  B. 
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Figure  5.  Real  Time  Manual  Control  Loop 
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C.  PROTOTYPE  ARCHITECTURE 


Hardware  decisions  were  based  on  computational  requirements  plus  the 
need  to  simulate  several  F-16  displays.  The  HUD  symbols  and  alphanu¬ 
meric  characters  provided  the  most  demanding  requirement.  A  combination 
of  home  computer  "video  game”  graphics  plus  a  calligraphic  display  was 
chosen  to  meet  these  requirements,  and  the  details  are  given  in  Section 
III.  An  Intel  8086  and  multibus  system  were  chosen  to  meet  the  real¬ 
time  corapution  update  requirement  which  must  be  accomplished  at  an 
update  rate  of  20  Hz  or  greater.  The  8086  supports  a  variety  of  operat¬ 
ing  systems,  e. g. ,  CP/m-86,  MS-DOS,  and  IAPX-86  thereby  allowing  the 
real-time  dynamics  to  be  implemented  in  a  higher  level  language. 

An  Atari  microcomputer  was  chosen  to  mechanize  the  HUD  end  SCP  dis¬ 
plays  and  auditory  feedback.  A  “video  game"  computer  such  as  the  Atari 
is  ideal  for  this  task  since  it  has  special  hardware  with  convenient 
software  interface  for  creating  video  displays  and  sounds.  An  inexpen¬ 
sive  color  monitor  or  TV  set  can  be  used  to  provide  the  display  and  the 
audio  system.  A  second  processor  combined  with  another  inexpensive  TV 
was  selected  for  the  stores  control  panel  display.  A  block  diagram 
showing  a  proposed  prototype  hardware  configuration  is  given  in  Fig.  6. 
The  use  of  the  low-cost  Atari  system  for  the  targeting  display  also 
established  a  framework  for  upgrading  the  color  video  system  as  new  com¬ 
puter  game  technologies  emerge. 

D.  PHYSICAL  LAYOUT 

Proposed  physical  layouts  for  a  F-16  HUD  trainer  are  illustrated  in 
Fig.  7.  The  general  configuration  is  designed  to  appear  like  the  cowl¬ 
ing  and  instrument  panel  of  the  F-16.  The  "outside  world”  display  is 
mounted  on  top,  while  the  HUD  video  monitor  is  mounted  inside,  and 
reflected  off  a  mirror  and  the  combining  glass  as  illustrated.  The 
remainder  of  the  enclosure  can  be  used  for  mounting  the  multibus  card 
cage  for  the  8086  and  HUD  graphics  boards,  and  also  for  mounting  the 
Atari  microcomputers.  Photographs  of  mockups  for  both  table  top  and 
freestanding  physical  configurations  are  shown  in  Fig.  8.  Finally,  a 
potential  sit  down  configuration  is  shown  in  Fig.  9,  which  could  Include 
future  enhancements  such  as  radar  displays. 
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SECTION  III 


DISPLAY  DEVELOPMENTS 


A.  OVERVIEW 

Graphics  displays  for  meeting  complexity  and  computational  update 
requirements  obviously  presented  the  most  difficult  technical  challenge 
on  this  project.  Special  graphics  systems  were  obviously  out  of  the 
question  because  of  cost.  Personal  computer  graphics  systems  appeared 
to  hold  the  only  prospect  of  providing  a  cost  effective  solution.  Some 
home  computers  have  developed  special  graphics  IC's  which  permit  over¬ 
laying  objects  on  display  fields  through  DMA  like  operations.  Graphics 
boards  developed  for  use  with  microcomputer  systems  also  permit  certain 
types  of  fast  graphics  processing.  This  effort  started  out  with  a  sur¬ 
vey  of  low-cost  approaches.  Two  commercial  systems  were  tried,  and  a 
special  purpose  system  was  developed  on  this  project  to  meet  the  need 
for  a  fast  update  display  generator  that  could  portray  six  degree-of- 
freedom  motion  (i.e.  ,  roll,  pitch,  yaw;  up,  down,  sideways).  Details 
are  given  below. 

B.  DISPLAY  APPROACHES 


From  a  manual  control  and  human  factors  point-of-view,  dynamic 
flight  displays  must  meet  three  requirements: 

»  they  should  appear  to  move  smoothly 

*  they  should  not  appear  to  flicker  or  flash  which 
can  be  distracting  and  cause  visual  fatigue 

•  they  should  not  present  significant  time  delays 
which  can  cause  the  control  tasks  to  seem 
unnaturally  sluggish  and  potentially  be  uncon¬ 
trollable 


These  requirements  are  discussed  in  some  detail  in  Appendices  A  and  B. 
Three  display  approaches  were  considered  to  meet  the  above  requirements: 

®  Atari  home  computer  system  which  uses  a  proprie¬ 
tary  u  processor  controller  for  animating  a  color 
raster  display  field  and  movable  DMA  (dynamic 
memory  access)  elements  referred  to  as  "sprites'* 
or  "players" 

o  A  high  resolution  digital  system  for  drawing 
vectors  based  on  the  NEC  7220  v  processor 

•  A  digitally  controlled  analog  system  for  drawing 
vectors  on  a  linear  CRT 

A  summary  of  the  capabilities  of  these  three  systems  is  given  in 
Table  1.  Initially  we  attempted  to  mechanize  both  the  HUD  display  and 
out-the-window  real  world  scenes  in  an  Atari  home  computer.  The  Atari 
has  proven  excellent  for  allowing  rapid  movement  of  display  elements  in 
a  rectangular  orientation  as  will  be  discussed  subsequently.  Figure  10 
shows  an  Air-to-Air  mode  display  which  allows  movement  of  several  reti¬ 
cles  and  linear  scales.  The  interface  has  been  worked  out  to  drive  the 
HUD  display  elements  from  the  system's  8086  host  processor. 

The  Atari  was  also  used  to  mechanize  the  SCP  (Stores  Control  Panel) 
display  as  discussed  in  III-D.  The  HUD  and  SCP  mechanizations  have  two 
basic  characteristics  in  common  that  make  them  ideal  for  the  Atari 
application:  they  require  minimal  computation  and  they  basically  have  a 

rectangular  orientation. 

In  our  attempts  to  develop  an  out-the-window  display,  we  were  able 
to  simulate  perspective  scene  motions  relative  to  pitch,  yaw,  and 
lateral  translation  motions  of  the  observer.  Because  of  the  slow  compu¬ 
tational  speed  of  the  Atari  host  processor  (a  Mostek  6502  running  on  a 
2.8M  Hz  clock)  rolling  the  display  in  real  time  would  be  virtually 
impossible,  and  adding  other  degrees  of  freedom  would  be  prohibitive  in 
terms  of  assembly  language  development.  The  out-the-window  scene  devel¬ 
opments  indicated  that  the  Atari  would  be  useful  for  ground  vehicle  dis¬ 
plays  which  do  not  have  to  roll  or  change  altitude  (relative  eye 
height).  Some  arcade  and  home  video  games  have  in  fact  demonstrated 
this  capability  (e.g.,  "Pole  Position"). 
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TABLE  1.  LOW  COST  DISPLAY  TECHNOLOGY  ASSESSMENT 


Atari 

•  Good  for  rectangular  oriented  formats 

•  Can  animate  players  and  play  field 

•  Rapid,  smooth  slewing 

•  Cannot  do  roll 

•  Must  minimize  computations 

•  Color  priorities,  hit  detection 

•  Sound 

[Good,  fast,  low-cost  rectangular  graphics  system] 

NEC  7220-uP  Systems  (Ikier,  Vectrix,  NEC,  ...) 

•  Significant  overhead  to  load  chip  with  instructions 

•  Typical  vectors  require  ~  5  msec  for  draw  and  erase 

•  Circles  require  8  vectors 

•  For  20  Hz  update  rate  can  generate  10  vectors 
[Not  adequate  for  complex  real  time  dynamic  displays] 

Calligraphic  systems 

•  >  100  vectors  in  non  flash  mode 

•  can  perform  analog  transformations  with  no  delay  penalty 

•  High  resolution,  smooth  movement 

[Best  approach  for  moderate  cost,  complex  scene  generation! 
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a)  Display  and  Computer 


1.2 


b)  Display  Close-up 
Figure  10.  Atari  Generated  HUD  Display 
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The  second  system  we  investigated  employed  a  NEC  7220  u  processor  to 
generate  vectors  with  800  *  1024  pixels  on  a  digitally  (TTL)  driven  dis¬ 
play.  The  NEC  chip  has  several  built  in  modes  which  allow  for  drawing 
arcs,  vectors,  and  filling  in  polygons.  This  is  a  very  appealing 
approach  and  a  number  of  digital  graphics  and  p  computer  systems  are  now 
using  the  NEC  chip  as  a  graphics  controller.  Our  own  experience  has 
shown  the  NEC  chip  to  be  too  slow  for  real  time  display  applications, 
however.  Two  NEC  based  systems  were  benchmarked.  One  included  in  an 
8086  development  system  acquired  for  this  project,  and  another  in  incor¬ 
porated  in  a  different  commercial  product. 

An  array  of  15  bytes  must  be  loaded  into  the  NEC  chip  for  every 
vector  draw,  17  for  each  arc  sector  and  rectangle  and  7  for  a  single 
dot.  For  animation,  vectors  must  be  erased  and  redrawn  at  a  new  loca¬ 
tion.  A  further  limitation  is  that  the  maximum  arc  sector  only  extends 
for  45  deg,  so  a  full  circle  requires  8  consecutive  arc  sector  loads  or 
136  byte  transfers  plus  housekeeping.  We  found  that  about  5  msec  were 
required  for  a  draw  and  erase,  so  that  even  at  a  fairly  slow  update  rate 
of  20  Hz  only  about  10  vectors  can  be  generated  (barely  enough  for  one 
circle!).  It  should  be  noted  that  the  specifications  for  the  NEC  based 
systems  do  not  relate  to  this  update  issue.  Their  applications  are 
intended  more  towards  CAD/CAM  where  several  seconds  might  be  adequate 
for  a  display  update. 

The  above  low  cost  approaches  are  clearly  not  adequate  for  real 
world  out-the-window  scenes,  and  for  this  we  decided  to  return  to  the 
third  approach  shown  in  Table  l,  a  calligraphic  or  analog  waveform  sys¬ 
tem  drawn  on  a  linear  CRT.  The  attitude  and  translation  transformations 
required  for  real  world  perspective  motion  can  be  accomplished  with  ana¬ 
log  multipliers  which  essentially  work  with  no  computational  delay. 
This  approach  has  been  used  quite  successfully  in  the  past  for  ground 
vehicle  simulator  displays  (Ref.  5).  To  make  this  approach  more 
general,  however,  the  waveforms  for  the  basic  three  dimensional  map  were 
generated  digitally.  The  digital  waveform  generation  technique  has  been 
developed  previously  (Ref.  6)  and  we  were  able  to  test  this  approach 
with  our  transformation  system.  Our  feasibility  tests  showed  that  over 
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100  arbitrary  vectors  could  be  generated,  transformed,  and  displayed 
with  high  resolution,  smooth  motion,  no  flicker  at  a  fairly  high  update 
rate  (~  50  Hz). 

Based  on  the  above  assessments,  we  decided  to  use  the  Atari  graphics 
approach  for  HUD  rectangular  graphics  and  the  SCP  display.  The  callig¬ 
raphic  approach  was  used  for  real  world  out-the-window  scenes  and  the 
HUD  attitude  bars  which  must  rotate  with  the  aircraft's  roll  angle  as 
well  as  translate  for  pitch. 

C.  ATARI  GRAPHICS  COMPUTER  AND  8086  INTERFACE 

A  closeup  of  the  air-to-air  mode  display  implemented  on  the  Atari  is 
shown  in  Fig.  11.  In  this  display,  there  are  three  symbol  categories 
thllt  must  be  updated  with  information  from  the  8086  host  processor: 

•  linear  moving  scales:  vertical  moving  airspeed 

and  altitude  scales,  and  the  horizontal  heading 
scale 

•  targeting  symbols  with  vehicle  and  horizontal 

movement:  air-to-air  aiming  reticle,  target 

designator  box,  and  flight  path  marker 

®  alphanumeric  information  in  15  "windows:''  e.g.  , 
vertical  g's,  heading,  weapons  mode,  etc. 

Two  parallel  ports  are  used  to  pass  alphanumeric  and  movement  infor¬ 
mation  for  the  above  symbols  between  the  8086  and  the  Atari.  The  infor¬ 
mation  is  contained  in  a  30  byte  block.  Under  free  running  conditions 
we  have  achieved  a  data  rate  of  6000  bytes/sec.  In  order  to  be  able  to 
pass  all  required  information  during  the  Atari's  vertical  blanking 
interval,  the  display  update  rate  is  run  at  30  times  a  second.  The 
Atari  still  maintains  a  60  Hz  video  refresh  rate,  however,  so  that  no 
flicker  is  evident.  Different  portions  of  the  display  are  updated  on 
alternate  frames. 

D.  STORES  CONTROL  PANEL  (SCP) 

As  discussed  previously,  the  SCP  was  not  included  in  our  original 
concept  for  the  F— l 6  HUD  trainer,  but  subsequent  discussions  with  pilots 


MOVING  SYMBOLS 


ALPHANUMERIC  MOVING  TAPE 

WINDOWS  SCALES 


Figure  11.  Atari  Graphics  Computer  HUD  Display 

and  training  simulation  personnel  implicated  it  as  an  integral  part  of 
the  HUD  training  problem.  Preliminary  analysis  of  the  SCP's  functional 
requirements  proved  it  to  be  well  suited  for  simulation  on  an  Atari 
microcomputer.  Modification  of  the  standard  Atari  character  font 
allowed  us  to  simulate  the  special  9  segment  panel  characters  on  an 
ordinary  TV  set. 

The  logic  for  the  SCP  display  and  keyboard  input  were  implemented  in 
Atari  Basic.  Several  typical  SCP  display  formats  are  illustrated  in 
Fig.  12a.  The  displayed  buttons  were  subsequently  replaced  by  a  switch 
panel  as  shown  in  Fig.  12b  which  interfaced  with  the  Atari  keyboard 
input  port.  Most  of  the  weapon  modes  were  represented  in  the  software, 
which  could  easily  be  updated  or  augmented  to  accommodate  additional  or 
altered  weaponry. 
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SCP  Display  Examples 


In  order  to  have  the  SCP  automatically  boot  on  power  up,  we  intended 
to  compile  the  Atari  Basic  and  then  store  the  object  code  on  a  ROM.  We 
were  successful  in  putting  the  HUD  graphics  code  on  a  ROM,  but  the  SCP 
effort  was  not  completed. 

E.  CALLIGRAPHIC  DISPLAY  PROCESSOR 

The  calligraphic  processor  was  designed  as  a  low  cost  solution  to 
the  problem  of  rapid  manipulation  of  arbitrary  vectors  on  a  linear  x-y 
CRT.  The  processor  consists  of  two  major  elements:  1)  a  digital  wave¬ 
form  generator  which  draws  three-dimensional  (rectangular  coordinate) 
maps  relative  to  observer  position  from  memory  stored  coordinates;  2)  an 
analog  transformation  system  which  provides  angular  transformations  for 
orLenting  the  observer's  line  of  sight  and  a  perspective  transformation 
for  drawing  images  within  the  observer's  field  of  view  on  the  display 
plane. 

A  block  diagram  of  the  overall  processor  system  is  shown  in  Fig.  13. 
The  digital  waveform  generator  is  a  single  multibus  card  which  plugs 
directly  into  the  8086  bus.  The  card  contains  a  Z80  microprocessor, 
64K  bytes  of  memory  (an  arbitrary  mix  of  RAM  and  ROM),  and  hybrid  cir¬ 
cuitry  which  generates  x,  y,  and  z  axis  analog  waveforms,  associated 
blanking  pulses  and  an  intensity  control  waveform.  The  8086  can  write 
directly  into  the  Z80  memory  space  to  update  the  observer's  viewing 
position  (x,  y,  z  coordinates)  within  the  three-dimensional  map.  Memory 
conflicts  are  arbitrated  by  a  hardware  bus  lockout  when  the  Z80  is  read¬ 
ing,  and  by  a  shared  software  semaphore  flag  which  the  8086  uses  when  it 
writes  address  data  into  Z80  RAM.  The  computational  load  on  the  Z80  is 
minimal,  consisting  of  memory  fetch  and  a  fixed  point  add  to  update  the 
observer  position  for  each  vector  and  point.  Thus  the  vector  rate  of 
the  processor  is  relatively  high,  running  about  8000  vectors  per  second. 
At  a  50  Hz  update  rate  to  minimize  flicker,  we  can  nominally  present 
display  scenes  with  about  160  vectors.  (For  future  upgrades,  a  faster 
16  bit  processor  would  allow  more  vectors  and  finer  resolution.) 

The  digital  waveform  generator  sends  x,  y,  z,  and  intensity  signals 
in  the  form  of  a  three-dimensional  vector  to  an  analog  transformation 


Calligraphic  Display  Processor  System 


processor  (see  Fig.  13),  which  consists  of  angular  and  perspective 
transformation  circuitry.  The  angular  transformations  are  driven  by  the 
vehicle  direction  cosine  matrix  derived  from  equations  of  motion  in  the 
8086  host.  They  are  then  converted  to  analog  voltages  and  transmitted 
to  the  transformation  processor  via  auxiliary  cable.  This  approach 
guarantees  that  angular  motions  exhibit  minimal  display  processor  lag. 
Minimization  of  angular  response  lags  is  crucial  in  flight  simulation. 
Since  a  pilot's  broadest  bandwidth  requirements  are  in  attitude  control, 
which  is  highly  sensitive  to  computational  delay. 

One  powerful  feature  of  our  approach  to  display  generation  is  that 
each  vector  is  individually  tagged  for  the  categories  of  transformations 
to  be  applied  to  it  by  the  transformation  hardware.  As  noted  in  the 
Fig.  13  block  diagram,  the  Z80  microprocessor  sends  a  transformation 
attribute  code  with  each  vector.  The  attribute  code  is  then  used  by  the 
transformation  processor  to  select  which  of  several  sets  of  transforma¬ 
tions  will  be  applied  to  the  vectors.  For  example,  this  approach  allows 
us  to  generate  HUD  pitch  scales  which  only  require  roll  transformation, 
airplane  referenced  vectors  (e.g. ,  gun  tracers)  which  only  go  through 
the  perspective  transformation,  and  perhaps  other  HUD  symbology  that 
does  not  require  any  transformation  at  all. 

Photos  of  several  display  configurations  are  shown  in  Fig.  14.  This 
graphics  approach  allows  for  relatively  complex  programmable  scene 
generation  with  low  computational  delays.  The  hardware  is  inherently 
low  cost,  and  allows  for  additional  future  enhancement  of  speed  and 
capacity.  This  type  of  calligraphic  system  could  potentially  provide 
for  curved  vectors  (not  just  straight  line  approximations)  and  limited 
fill  capability.  Also,  some  color  capability  could  be  added  by  using  a 
shadow  mask,  stroke-writing  linear  CRT.  Further  discussion  is  given  in 
Appendix  C. 


Figure  i4.  Calligraphic  Display  Scenes  Including  Horizon,  Ground  Grid,  and  HUD  Pitch  Scale 


SECTION  IV 


HOST  PROCESSOR  CONFIGURATION  AND  COMPUTATIONS 


A.  OVERVIEW 

As  noted  in  the  prototype  architecture  of  Fig.  6,  an  Intel  8086 
microprocessor  with  an  8087  math  co-processor  was  selected  for  the  cen¬ 
tral  host  processing  chores.  FORTRAN  software  and  some  assembly 
language  subroutines  were  run  under  the  CP/M  86  operating  system.  As 
discussed  in  Section  II-C  the  host  processor  was  designated  to  handle 
the  overall  housekeeping  functions  and  carry  out  the  computationally 
intensive  real-time  computations.  In  this  role  the  host  processor  had 
to  provide  drive  commands  for  the  Atari  HUD  and  the  out-the-window 
vector  graphics  system,  and  accept  commands  from  the  Stores  Management 
Subsystem,  stick,  and  throttle.  Details  on  successfully  completed  parts 
of  the  host  system  software  were  as  follows. 

B.  REAL-TIME  DYNAMICS 

The  Intel  8086  system  was  configured  to  run  under  CP/M-86  which,  in 
turn,  was  configured  to  support  a  subset  of  iAPX  86,88  which  was  origi¬ 
nally  developed  for  the  Intel  MDS.  This  was  necessary  in  order  to  run 
Intel's  FORTRAN  77  which  was  the  only  available  FORTRAN  with  support  for 
the  8087  floating  point  math  co-processor.  For  the  first  software 
development  on  the  system  we  chose  to  implement  a  simple  equivalent  sys¬ 
tems  version  of  the  F-16  flight  dynamics  as  summarized  in  Fig.  15. 
Because  the  F-16  is  highly  augmented  with  a  sophisticated  stability  aug¬ 
mentation  system  (SAS),  the  attitude  control  dynamics  were  modeled  with 
a  simple  first  order  lag. 

The  F-16  has  a  high  thrust  to  weight  ratio  and  can  sustain  vertical 
flight,  so  quarternions  were  employed  to  integrate  Euler  angles  through 
all  possible  flight  attitudes.  Simple  body  axis  acceleration  equations 
were  also  employed  in  order  to  correctly  represent  Lift,  thrust,  and 
drag.  Thus,  the  dynamics  correctly  represented  speed  and  rate  of  climb 
in  response  to  thrust  changes  and  attitude  maneuvering. 


r-16  Dynamics  Computation  Cycle  Data  Flow 


In  order  to  simplify  the  development  and  checkout  of  the  flight 
dynamic  equations,  they  were  first  tested  on  a  DEC  PDP  11/34  system. 
They  were  then  transferred  by  disk  media  to  a  PDP  11/10  where  they  were 
down-loaded  to  the  Intel  8086  system  using  data  communication  utilities. 
Although  this  process  was  pursued  as  a  matter  of  programming  expedience 
it  also  allowed  us  to  obtain  benchmarks  on  the  running  speed  of  the 
real-time  dynamics  which  were  quite  impressive. 

The  benchmarks  were  obtained  by  running  the  dynamics  at  a  50  msec 
update  rate  for  600  iterations  which  is  equivalent  of  a  real-time  period 
of  30  seconds.  The  actual  amount  of  computational  time  taken  by  various 
computer  configurations  is  shown  in  Fig.  16.  The  Intel  8086  without  the 
8087  (using  software  evaluation  for  floating  point  calculations) 
required  570  seconds  for  the  equivalent  of  30  seconds  real-time  computa¬ 
tion!  With  the  8087  co-processor  the  time  reduced  to  4.6  seconds.  Thus 
the  real-time  task  would  be  impossible  without  the  8087  support.  Note 
also  in  Fig.  15  that  the  8086/8087  is  about  8  times  faster  than  a  PDP 
11/10  minicomputer  but  only  a  half  as  fast  as  a  PDP  11/34  minicomputer 
with  floating  point  math  hardware. 

The  above  exercise  has  demonstrated  the  8086/8087  system  to  be  a 
very  powerful  processor.  The  8086  was  originally  selected  because  of 
the  availability  of  the  8087,  and  real-time  software  effort  has  vindi¬ 
cated  this  decision.  It  would  appear  that  the  8086/8087  system  is  a 
good  general  choice  for  training  systems  where  inexpensive  but  fast 
floating  point  arithmetic  is  required. 

C.  INTERFACE  SOFTWARE 

During  real-time  operation  part  of  the  8086  host  processor's  task 
was  to  service  the  various  display  devices.  As  discussed  in  Section 
III-C,  the  Atari  HUD  commands  were  sent  through  a  parallel  data  port 
using  a  packet  protocol.  The  vector  drawing  system  commands  were  pro¬ 
cessed  through  a  general  housekeeping  module  to  coordinate  the  various 
display  components  (l.e.,  ground  grid,  horizon,  attitude  bars)  then  com¬ 
municated  through  shared  memory  with  the  Z80  processor  which  controlled 
the  composite  data  base.  The  analog  angular  coordinate  system  trans¬ 
formations  were  driven  through  D/A  converters  from  the  8086. 


Figure  16.  Run  Time  Benchmarks  for  Six  Degree-of-Freedom  Aircraft  Dynamics 


Checkout,  debugging,  and  real-time  tests  were  just  commencing  when 
work  on  the  project  was  suspended.  The  basic  communication  protocols 
worked  without  any  apparent  conflicts.  Some  work  was  still  required  to 
make  the  housekeeping  functions  for  the  vector  display  system  more  effi¬ 
cient  in  order  to  meet  the  real-time  update  goal  of  more  than  20  intera- 
tions  per  second.  This  work  appeared  to  be  straightforward,  however, 
and  a  matter  of  developing  several  assembly  language  modules  which  would 
be  linked  in  with  the  real-time  FORTRAN  portion  of  the  host  processor 
code. 
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The  efforts  documented  In  this  report,  although  not  carried  to  com¬ 
pletion,  clearly  demonstrate  the  feasibility  of  developing  low-cost  sim¬ 
ulator  hardware  using  commercially  available  microprocessor  elements. 
Personal  computer  technology  is  advancing  rapidly,  with  increasing  capa¬ 
bility  and  decreasing  cost.  Current  state-of-the-art  microprocessors 
plus  math  co-processors  exhibit  adequate  computing  power  and  speed  for 
many  applications.  Display  co-processors  also  allow  relatively  complex 
displays  at  fast  update  rates.  Indications  are  that  microprocessor  per¬ 
formance  developments  will  continue  in  the  near  future  as  16  and  32  bit 
applications  mature.  Display  hardware  boards  designed  to  operate  on 
personal  computer  busses  will  also  increase  in  capability,  including  the 
capability  for  combining  video  disk  and  computer  generated  imagery. 

Specific  advancements  on  this  project  which  might  find  future  appli¬ 
cation  include  microcomputer-generated  HUD  and  stores  control  panel  dis¬ 
plays,  a  low-cost  fast  update  rate  vector  drawing  processor,  and  simpli¬ 
fied  six  degree-of-f reedora  vehicle  dynamics.  These  developments  are 
suitable  for  implementation  with  current  microprocessor  hardware,  and 
would  exhibit  significantly  improved  capability  with  advanced  16  or 
32  bit  processors.  Future  applications  should  take  into  account  the 
real-time  display  update  requirements  discussed  in  Appendices  A,  B,  and 
C,  however,  so  as  to  avoid  achieving  increased  capability  in  scene  com¬ 
plexity  at  the  expense  of  throughput  delays  and  inadequate  update  rates. 
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APPENDIX  A 


* 


* 


COMPUTATIONAL  CONSIDERATIONS  IN  REAL-TIME 
SIMULATION  COMPUTER  GRAPHICS 


A.  OVERVIEW 

The  display  interface  is  a  critical  element  in  the  manual  control  of 
vehicles.  A  well  designed  display  device  should,  at  a  minimum,  not  com¬ 
plicate  the  human  operator's  control  task;  in  fact,  good  synthetic  dis¬ 
plays  should  augment  the  operator's  control  capability.  Advances  in 
digital  technology  and  CRTs  are  causing  a  revolution  in  real-time  simu¬ 
lation;  and  general  improvements  in  computer  graphics  offer  a  range  of 
computational  techniques  for  creating  complex  formats. 

The  problems  encountered  in  digitally  generated  simulation  displays 
involve  computational  and  refresh  update  rates,  and  various  effects 
arising  from  the  quantized  nature  of  digital  computations.  The  human 
operator  requires  a  display  presentation  with  smooth  apparent  motion, 
and  without  significant  delay  of  visual  information  feedback.  This 
appendix  discusses  the  nature  and  implications  of  various  quantization 
related  artifacts  in  visual  display  systems. 

B.  INTRODUCTION 

Visual  displays  are  the  primary  means  for  providing  feedback  to  the 
human  operator  in  vehicle  control  tasks  such  as  car  driving  and  aircraft 
piloting.  Synthetic  displays  are  used  to  supplement  or  replace  real 
world  cues  under  conditions  of  reduced  visibility  aircraft  operations, 
and  in  a  wide  range  of  simulator  applications  (i.e.  ,  ground  vehicle, 
marine,  aircraft,  and  spacecraft).  To  be  effective,  synthetic  visual 
feedback  displays  should  accurately  represent  the  visual  cues  required 
by  the  human  operator.  Display  accuracy  applies  to  both  scene  content, 
and  temporal  considerations  associated  with  intensity,  apparent  motion, 
and  delays  in  generating  the  displayed  information. 
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Electromechanical  Instruments,  and  analog  simulations  including 
video/terrain  model  displays,  in  the  past  provided  acceptable  display 
solutions  but  lacked  flexibility  in  changing  formats  and/or  creating 
various  visual  effects.  The  advent  of  computer  generated  imagery  (CGI) 
has  overcome  many  of  the  previous  limitations,  but  has  added  a  host  of 
new  concerns  including  computational  delay,  scene  update  rate,  and  quan¬ 
tization  effects.  Recent  advances  in  display  processing  architecture 
and  algorithms  are  largely  overcoming  basic  problems  in  presenting  ade¬ 
quate  scene  content,  but  acceptable  computational  delay  is  still  an 
unresolved  issue. 

There  is  an  obvious  tradeoff  between  visual  scene  complexity,  scene 
update  rate  and  computational  delay.  An  appropriate  balance  among  these 
three  factors  is  difficult  to  specify,  however,  and  depends  heavily  on 
the  specific  nature  of  the  human  operator's  task.  In  cases  where  subtle 
visual  cues  are  important  and  are  near  human  visual  perceptual  thres¬ 
holds,  scene  content  and  complexity  will  be  most  important.  On  the 
ocher  hand,  in  situations  where  rapid  vehicle  maneuvering  is  required 
under  high  bandwidth  closed-loop  control,  computational  delay  and  scene 
update  rate  are  obviously  of  great  importance.  Attention  in  the  litera¬ 
ture  has  been  heavily  slanted  towards  considerations  of  scene  realism, 
encoding  of  geometric  information,  spatial  orientation,  etc.  (e.g. , 
Ref.  A-l).  In  this  appendix,  the  temporal  aspects  of  computer  generated 
imagery  are  emphasized,  particularly  with  regard  to  the  human  operator's 
need  for  visual  feedback  in  exerting  tight,  high  bandwidth  closed-loop 
control. 

C.  DISPLAY  REQUIREMENTS  AND  EVALUATION  CRITERIA 

From  the  human  operator's  point  of  view,  a  synthetic  display  should 
provide  a  smooth  representation  of  vehicle  motions  associated  with  posi¬ 
tion  and  angular  orientation.  Many  tasks  require  the  operator  to  anti¬ 
cipate  future  motion  (commonly  referred  to  as  lead  generation),  so  chat 
the  display  representation  should  be  sufficiently  rich  and  frequent  to 
allow  the  estimation  of  the  velocity  or  rate  of  change  of  displayed 
variables.  The  adequacy  of  synthetic  displays  for  providing  such  cues 
can  be  evaluated  from  several  points  of  view. 


In  real  world  applications  such  as  displays  for  vehicle  control,  we 
are  concerned  about  the  adequacy  of  system  performance  and  minimizing 
the  potential  for  human  error.  For  simulator  applications  the  concern 
relates  to  the  comparability  of  simulation  vs.  real-world  system  experi¬ 
ence.  For  research  simulators  we  wish  to  have  fairly  broad,  pure  com¬ 
parability.  For  training  applications,  we  care  primarily  about  the 
degree  to  which  simulator  experience  translates  to  real-world  system 
operation  and  in  some  sense  makes  training  safer  and  more  cost  effective 
(e.g. ,  Ref.  A-2).  For  licensing  and  certification  applications,  the 
primary  issue  is  whether  a  simulator  can  provide  an  appropriate  criter¬ 
ion  or  metric  for  subsequent  human  operator  performance  —  a  target 
real-world  system.  (In  some  sense  a  simulator  might  provide  a  better 
test  than  the  actual  real-world  system  because  failure  modes  and  incipi¬ 
ent  accident  scenarios  might  be  simulated  that  would  be  too  hazardous  to 
attempt  a  real  vehicle. ) 

Two  general  simulation  evaluation  criteria  that  will  be  considered 
in  this  appendix  are  fidelity  and  validity.  Fidelity  relates  to  the 
human  operator's  subjective  experience  in  a  simulator,  and  whether  his 
responses  are  consistent  with  the  way  he  would  react  in  the  real  world. 
Validity  is  concerned  with  more  objective  realism  such  as  whether  engi¬ 
neering  system  response  measurement  and  performance  results  are  compar¬ 
able  between  simulator  and  the  real  world. 

Simulator  fidelity  can  relate  to  sensory  feedbacks  other  than  dis¬ 
play  systems  (e.g.,  proprioceptive,  motion,  and  auditory  cues)  and  can 
interact  to  a  significant  degree  with  visual  display  fidelity  and  valid¬ 
ity  (e.g.  ,  the  coordination  of  visual  and  other  cues).  The  primary  pur¬ 
pose  of  this  appendix  is  to  consider  CGI  display  issues,  however,  and  in 
particular  their  temporal  characteristics.  The  temporal  characteristics 
to  be  addressed  include  refresh  rate  for  avoiding  flicker,  scene  update 
rate  to  achieve  smooth  apparent  motion,  and  overall  throughput  computa¬ 
tional  delay  which  affects  system  dynamic  response  (a  good  current 
review  of  temporal  effects  aside  from  computational  delay  can  be  found 


Refresh  requirements  to  minimize  flicker  are  fairly  well  understood, 
and  are  reviewed  next  for  context,  because  they  are  sometimes  confused 
with  update  rate  requirements  for  achieving  the  illusion  of  smooth 
apparent  motion.  Discussion  next  turns  to  apparent  motion  effects  which 
are  quite  complex  and  less  well  understood  than  the  flicker  problem. 
The  update  rate  requirement  for  achieving  smooth  motion  is  often  con¬ 
fused  with  the  computational  throughput  requirements  for  minimizing 
delays  in  visual  feedback  information.  The  computational  delay  issue, 
which  is  the  final  topic  discussed  here,  has  received  much  engineering 
attention  since  the  introduction  of  digital  computers  into  simulation 
technology,  but  requirements  are  still  not  very  well  understood. 

D.  DISPLAY  REFRESH  RATE  AND  FLICKER 

The  steadiness  or  constancy  of  display  brightness  is  determined  by 
the  sensory  characteristics  of  the  retina.  Light  sources  with  varying 
brightness  will  be  perceived  as  flickering  depending  on  the  absolute 
brightness  and  relative  amount  and  timing  of  brightness  variations. 
Much  early  research  was  accomplished  with  flashing  light  sources  and 
rotating  mechanical  apparatus  which  periodically  controlled  the  appear¬ 
ance  of  light  and  dark  areas  (see  reviews  in  Refs.  A-4  through  A-7). 

Over  a  fairly  wide  luminance  range  relevant  to  visual  displays, 
refresh  rates  required  to  avoid  flicker  are  a  logarithmic  function  of 
display  screen  brightness  as  illustrated  in  Fig.  A-l.  The  eye  is  gener¬ 
ally  more  sensitive  to  flicker  in  the  periphery  and  with  increases  in 
the  areas  of  the  flickering  field.  Common  video  refresh  rates,  typic¬ 
ally  50  or  60  Hz,  sometimes  appear  to  flicker  when  turned  up  to  high 
Intensity,  when  viewed  at  close  range,  and/or  when  viewed  peripherally. 
Interlaced  scanning  is  frequently  used  in  video  presentations  to  reduce 
bandwidth  and  computational  requirements.  In  this  case,  alternate  lines 
are  refreshed  once  every  other  scan,  which  reduces  the  scan  rate  of  an 
individual  line  to  25-30  Hz.  Frame  rates  for  ordinary  movies  run  at 
24  frames  per  second,  and  a  shutter  is  used  to  interrupt  each  frame  once 
or  twice  in  addition  to  the  interframe  blank  interval.  Early  research 
found  that  the  critical  flicker  frequency  or  CFF  varied  with  several 
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__  Figure  A-l.  Effects  of  Refresh  Rate  and  Image  Luminance  on 
Critical  Flicker  Frequency  (i.e.,  point  at  which 
image  appears  to  have  constant  brightness). 

Ferry-Porter  Law  shown  for  photopic  adaptation. 

Video,  movie  and  CRT  strobe  written  displays 
commonly  set  at  60  Hz  refresh  rate. 

parameters  associated  with  the  details  of  the  time  course  of  the  inten¬ 
sity  wave  form.  Subsequent  research  and  analysis  has  shown  that  most  of 
the  early  empirically  observed  effects  can  be  explained  by  a  temporal 
modulation  transfer  function  (Ref.  A-8),  which  is  basically  a  frequency 
response  function  for  visual  sensitivity  to  time  modulated  light. 

The  effects  of  Flicker  are  primarily  distracting  In  nature,  and  can 
lead  to  visual  discomfort.  Such  effects  are  reviewed  in  Ref.  A-6  with 
regard  to  design  apsects  of  video  display  terminals.  These  effects  can 
easily  result  in  some  degradation  of  a  graphics  display  in  terms  of 
fidelity.  More  important,  however,  would  be  the  influence  of  flicker  on 
the  perception  of  subtle  motion  cues.  Flicker  can  disrupt  the  pursuit 
of  smooth  motion  and  Interact  with  apparent  motion  effects  discussed 
next.  Peripheral  vision  is  most  sensitive  to  displayed  motion,  and  is 
also  most  sensitive  to  flicker  effects.  Thus,  wide  field  of  view  dis¬ 
plays  will  be  most  sensitive  in  this  regard. 
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E.  SCENE  UPDATE  RATE  AND  APPARENT  MOTION 


Computer  generated  displays  attempt  to  give  the  illusion  of  motion 
with  the  presentation  of  a  rapid  succession  of  static  scenes  or  frames. 
Smooth  appearing  motion  is  essential  in  a  vehicle  control  simulation  in 
order  that  the  human  operator  can  anticipate  vehicle  movement  (i.e. , 
referred  to  as  "lead  generation"  in  manual  control  terms.  Refs.  A-9  and 
A-10).  A  variety  of  effects  can  influence  the  illusion  of  smooth 
motion,  including  display  quantization  and  a  variety  of  perceptual 
effects  which  come  under  the  heading  of  apparent  motion. 

The  visual  system's  ability  to  resolve  digital  quantization  is 
fairly  well  characterized  by  a  spatial  modulation  transfer  function 
(Refs.  A-8  and  A-ll).  Classical  measures  of  visual  acuity  show  resolu¬ 
tion  down  to  a  few  minutes  of  visual  arc  (Refs.  A-4  and  A-5),  and 
spatial  MTF's  typically  show  spatial  bandwidth  on  the  order  of  10  cycles 
per  degree  (i.e.,  ~6  minutes  of  arc/cycle).  Therefore,  from  a  strict 
resolution  point  of  view,  display  quantization  should  be  on  the  order  of 
a  few  minutes  of  visual  arc  or  less  to  avoid  quantization  influence  on 
smooth  motion. 

Apparent  motion  in  computer  generated  displays  is  more  than  a  matter 
of  resolution,  however,  and  in  fact,  smooth  appearing  motion  can  be 
represented  with  resolutions  much  coarser  than  the  visual  systems  acuity 
limit.  The  illusion  of  apparent  motion  occurs  when  two  spatially  sepa¬ 
rated  stationary  images  are  displayed  in  rapid  succession.  The  factors 
influencing  the  perception  of  apparent  motion  involve  image  frame  rate, 
image  intensity,  and  image  displacement  between  frames.  With  adequate 
combinations  of  these  variables,  static  succeeding  images  will  appear  to 
flow  together  with  smooth  motion.  Also,  apparent  size  and/or  depth 
effects  can  be  achieved  through  the  control  of  image  brightness.  These 
two  types  of  apparent  motion  are  sometimes  referred  to  as  Seta  and  Gamma 
movement  respectively  (Ref.  A-12). 

Vehicle  control  simulations  require  perspective  displays  of  three- 
dimensional  scenes.  It  is  difficult  to  specify  frame  update  rate  and 
display  intensity  to  meet  apparent  motion  requirements  since  frame-to- 
frame  image  displacement  depends  on  simulated  vehicle  motion  which  is 


under  human  operator  control.  Both  vehicle  (observer)  attitude  and 
translation  motions  influence  image  displacements.  As  illustrated  in 
Fig.  A-2  vehicle  attitude  changes  in  pitch  (elevation  angle)  and  yaw 
(azimuth  or  heading  angle)  to  a  first  approximation  respectively  cause 
vertical  and  horizontal  displacements  of  the  perspective  display  plane 
image.  Thus  pitch  rate  and  yaw  rate  combined  with  the  scene  update  rate 
to  define  scene-to-scene  image  displacement.  Since  real  vehicles  have 
physical  limits  to  achievable  pitch  and  yaw  rates  under  normal  condi¬ 
tions,  display  characteristics  could  be  specified  accordingly. 


b)  Roll  (  Rot  at  ion) 

Figure  A-2.  Effects  of  Vehicle  Angular  Orientation 
on  Perspective  Display  Plane  Image  Motion 
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Changes  in  vehicle  roll  angle  require  the  display  to  rotate  about 
some  point  in  the  perspective  display  plane.  Image  velocity  is  highest 
at  the  display  edge  in  this  case,  and  maximum  roll  rates  can  be  defined 
for  a  given  vehicle  relative  to  specifying  display  requirements.  The 
horizontal  scan  lines  of  raster  scan  displays  present  a  particular  prob¬ 
lem  for  rotating  images.  Near  horizontal  lines  can  have  a  staircase 
appearance  which  can  create  both  static  and  dynamic  visual  cue  arti¬ 
facts.  Antialiasing  algorithms  can  make  significant  improvements  to 
this  situation. 

Perspective  plane  image  motions  resulting  from  vehicle  translation 
are  illustrated  in  Fig.  A-3.  Velocity  parallel  to  the  display  plane 
causes  scene  elements  closesr  to  the  observer  to  displace  more  rapidly 
than  more  distant  score  elements.  Because  of  characteristics  of  vehicle 
dynamics  and  motion  kinematics,  the  image  motions  caused  by  lateral  and 
vertical  vehicle  motions  are  usually  small  and  would  not  tend  to  influ¬ 
ence  the  specification  of  scene  update  rate. 

The  effect  of  vehicle  longitudinal  (forward)  velocity  can  have  a 
significant  impact  on  scene  update  rate,  however.  Velocity  normal  to 
the  display  plane  causes  scene  elements  to  have  increasing  angular 
velocity  as  they  move  towards  the  edge  of  the  display.  It  can  be  shown 
geometrically  that  this  is  not  a  matter  of  absolute  velocity,  but  of 
velocity  relative  to  the  range  of  an  object.  Thus,  ground  vehicles  and 
helicopters  can  generate  just  as  high  scene  expansion  rates  as  high 
speed  aircraft  because  they  typically  operate  in  closer  proximity  to 
scene  elements. 

The  several  types  of  vehicle-generated  scene  motion  described  above 
combine  to  determine  f rame-to-f rame  scene  displacements.  Scene  update 
rate  requirements  depend  on  providing  adequate  visual  control  cues  to 
the  human  operator,  and  avoiding  distracting  visual  artifacts.  A  large 
part  of  the  visual  information  required  by  a  human  operator  comes  from 
the  region  where  the  vehicle  velocity  vectors  converge  at  infinite  range 
(the  focus  of  expansion).  Thus,  while  some  f rame-to-f rame  stepping 
motion  in  the  periphery  is  probably  may  be  tolerated,  the  limiting 
parameters  have  not  been  firmly  established. 
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Horizon 


a)  Lateral  and  Vertical 


b)  Longitudinal 


Figure  A-3.  Effects  of  Vehicle  Translational  Motion  on 
Perspective  Display  Plane  Image  Motion 

Given  that  adequate  smooth  scene  motion  is  provided  to  the  human 
operator,  it  Is  likely  that  appropriate  visual  motion  cues  will  be  per¬ 
ceived.  Another  critical  factor  still  needs  to  be  considered,  however, 
and  that  is  the  degree  to  which  the  feedback  of  this  information  has 
been  delayed  by  computational  processing.  Rapid  scene  update  rates  that 
achieve  smooth  apparent  scene  motion  do  not  necessarily  imply  that  the 
feedback  information  was  supplied  to  the  human  operator  fast  enough. 
(Some  digital  display  processors  require  multiple  frame  intervals  for 
input  information  to  work  its  way  through  to  image  motions.)  The  influ¬ 
ence  of  the  speed  of  information  feedback  on  system  response  is  based  on 
manual  control  theory  which  Is  the  final  discussion  point  in  this  appen¬ 
dix. 

TR-1201-1  A- 9 


F.  COMPUTATIONAL  DELAY  AND  SYSTEM  DYNAMIC  RESPONSE 

In  current  simulator  mechanizations,  vehicle  equations  of  motion  are 
typically  solved  on  a  digital  computer,  which  then  drives  a  digital 
graphics  system.  This  architecture  leads  to  two  sources  of  computa¬ 
tional  delay  which  may  total  well  in  excess  of  100  msec.  The  effects  of 
computational  delay  on  simulator  performance  has  been  a  continuing 
source  of  concern  (Refs.  A-13  and  A-14),  but  guidelines  for  tolerable 
levels  of  delay  have  been  elusive. 

The  basic  problem  with  computational  delay  lies  in  its  effect  on  the 
human  operator's  closed-loop  control  of  vehicle  motions.  A  simplified 
model  of  a  manual  control  system  is  illustrated  in  Fig.  A-4.  This  model 
could  represent  the  dynamics  of  an  automobile  driver's  steering  task 
(Ref.  A-15),  or  even  a  rough  approximation  of  a  pilot/aircraft  tracking 
a  second  aircraft  (Ref.  A-16).  As  discussed  in  Ref.  A-15,  the  bandwidth 
of  this  system,  uc,  is  dictated  by  the  effective  time  delay,  Te.  The 
effective  time  delay  in  turn  is  a  composite  effect  of  the  human  opera¬ 
tor's  characteristics  and  vehicle  dynamics  (the  human  operator  compen¬ 
sates  for  the  vehicle  dynamics  to  a  certain  degree,  and  the  composite 
dynamics  can  be  crudely  modeled  as  a  time  delay). 

As  derived  in  Ref.  A-15  the  human  operator  can  Increase  the  system 
bandwidth  up  to  some  basic  stability  limit.  This  relationship  is  given 
in  Fig.  A-4,  which  is  composed  of  the  normalized  bandwidth  product, 
u)cTe»  a°d  another  composite  factor  associated  with  the  control  weighting 
the  operator  places  on  vehicle  translation,  Ky,  and  forward  velocity, 
U0.  Review  of  several  manual  control  research  studies  (Ref.  A-17)  has 
indicated  that  human  operators  typically  maintain  a  bandwidth  which 
allows  some  finite  stability  margin  (phase  margin  In  control  theory  par¬ 
lance).  As  system  equivalent  time  delay  increases  in  going  from  real 
vehicles  to  fixed  base  simulators,  human  operators  maintain  a  consistent 
stability  margin  by  reducing  system  bandwidth.  This  effect  Is  illus¬ 
trated  in  Fig.  A-5. 
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Figure  A-4.  Simplified  Crossover  Model  for  Manual  Vehicle  Control  and 
Stability  Requirements  (adapted  from  Ref.  A-15) 


Normalized  Bandwidth,  re  wc 


Figure  A-5.  Effect  of  Increased  Effective  Time  Delay 
on  System  Bandwidth  (Adapted  from  Ref.  A-15) 

Presumably,  the  addition  of  computational  delay  would  cause 
decreased  bandwidth  in  the  human  operator's  response  which  would  cer¬ 
tainly  have  consequences  in  system  response  and  performance.  In  the 
context  of  aircraft  handling  qualities,  pilot  opinion  rating  has  also 
been  shown  to  degrade  with  an  increase  in  equivalent  system  time  delay 
(Ref.  A-18).  Further  research  is  still  required  to  determine  all  of  the 
implications  of  computational  delays  and  their  interaction  with  other 
system  characteristics.  Some  previous  work  has  indicated  that  the  human 
operator  compensates  for  time  delays  (Ref.  A-19).  Other  work  suggests 
that  computer  system  compensation  can  also  be  used  to  partially  conter- 
act  some  of  the  effects  of  computational  delays  (Ref.  A-20). 

Further  research  and  analysis  is  required  in  order  to  completely 
understand  the  above  relationships.  It  should  be  noted,  however,  that 
human  operator  compensation  for  computationally  induced  time  delays  in 
simulators  represents  a  change  in  behavior  from  real  world  operations 
thus  presenting  a  fidelity  issue.  Reduced  system  bandwidth  due  to  added 
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time  delay  will  adversely  affect  system  performance  over  real-world 
operations  which  can,  in  turn,  degrade  effect  simulator  validity. 


A  comprehensive  study  of  the  dynamics  of  computational  delays  in 
simulators  should  be  conducted  so  that  display  manufacturers  will  have 
realistic  performance  criteria  available  when  making  tradeoffs  between 
scene  complexity  and  computational  delay.  Also,  the  requirements  of  a 
manual  control  system  may  help  define  optimum  architectures  for  computer 
display  processors.  For  example,  referring  to  Fig.  A-4,  it  can  be  shown 
that  delays  in  feedback  of  angular  motion  are  much  more  serious  than 
delays  in  translational  motion  which  are  one  integration  further  removed 
from  the  human  operator's  control  actions.  This  suggests  that  angular 
transformations  need  to  be  updated  most  frequently,  and  perhaps  transla¬ 
tional  transformations  could  be  updated  less  frequently  to  achieve  some 
savings  in  computation  time. 

G.  CONCLUDING  REMARKS 

As  reviewed  in  this  appendix,  there  are  a  variety  of  human  operator 
characteristics  that  must  be  taken  into  account  when  setting  require¬ 
ments  for  computer  generated  imagery.  The  temporal  requirements 
reviewed  here  relate  to  achieving  smooth  image  motion  and  minimizing 
computation  delay.  Further  research  is  required  in  aspects  of  apparent 
motion  and  the  effects  of  computational  delay  before  specific  require¬ 
ments  can  be  stated.  There  are  potential  tradeoffs  which  might  be  made 
in  display  processor  architecture  and  scene  complexity  vs.  update  rate 
once  the  human  operator's  requirements  are  more  completely  understood. 
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APPENDIX  B 

EFFECTS  OF  TRANSPORT  DELAYS  ON  MANUAL 
CONTROL  SYSTEM  PERFORMANCE 


A.  OVERVIEW 


Throughput  or  transport  delays  in  manual  control  systems  can  cause 
degraded  performance  and  lead  to  potentially  unstable  operation.  With 
the  expanding  use  of  digital  processors,  throughput  delays  can  occur  in 
manual  control  systems  in  a  variety  of  ways  such  as  in  digital  flight 
control  systems  in  real  aircraft,  and  in  equatlon-of-motion  computers 
and  CGI's  in  simulators.  Previous  research  has  shown  the  degrading 
effect  of  throughput  delays  on  subjective  opinion  and  system  performance 
and  dynamic  response.  A  generic  manual  control  system  model  is  used  in 
this  appendix  to  provide  a  relatively  simple  analysis  of,  and  explana¬ 
tion  for,  the  effects  of  various  types  of  delays.  The  consequences  of 
throughput  delays  of  some  simple  system  architectures  is  also  c’  cussed. 

B.  OVERVIEW  AND  BACKGROUND 

Past  literature  surveys  associated  with  flight  simulation  fidelity 
have  found  that  system  response  lags  and  computational  delays  cause  per¬ 
formance  and  pilot  subjective  rating  problems  (Refs.  B-l  and  B-2). 
Pilot/vehicle  model  analysis  has  shown  that  delays  on  the  order  of  50  to 
100  msec  can  have  an  appreciable  influence  on  performance  and  workload 
(Ref.  B-3),  Recent  experiments  have  shown  performance  effects  of  time 
delays  which  are  consistent  with  model  analysis  (Refs.  B-4  and  B-5). 

The  above  literature  indicates  that  simulator  computational  delays 
can  have  a  serious  effect  on  aircraft  simulation  fidelity.  Ground  vehi¬ 
cles  typically  have  faster  response  dynamics  than  aircraft  in  terms  of 
path  control,  and  it  Is  suspected  that  the  problem  may  be  even  more 
serious  for  driving  simulators.  To  further  understand  the  effect  of 
various  potential  sources  of  transport  delays  a  computer  model  analysis 
was  undertaken  using  a  generic  vehicle  control  model  as  described  below. 
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The  analysis  was  carried  out  to  study  the  effect  of  several  sources  of 
computational  delay  including  host  computer  system,  display  system,  and 
motion  system.  (This  analysis  does  not  address  another  important  simu¬ 
lation  artifact,  that  of  the  mismatch  between  visual  and  motion  cues, 
which  can  lead  to  vertigo  and/or  sickness.) 


C.  ANALYSIS  N9DEL 


The  basic  control  example  for  the  analysis  model  concerns  generic 
vehicle  tracking  (e.g. ,  dogfighting)  where  the  operator  must  point  his 
vehicle  at  a  target  or  aim  point  at  some  fixed  distance  in  front  of  the 
vehicle.  An  example  for  a  typical  aircraft  is  shown  in  Fig.  B-l 
(Ref.  B-6).  A  similar  arrangement  holds  for  ground  vehicle  steering 
control  as  illustrated  in  Fig.  B-2  (Ref.  B-7).  The  only  dynamic  differ¬ 
ence  between  the  car  and  aircraft  examples  is  the  Tq^  path  lag  which  is 
ignored  for  the  car.  (It  actually  exists  in  the  car,  but  as  a  very  high 
frequency  lag  corresponding  to  an  aircraft  with  steep  lift  or  side-force 
curve  slopes.) 


A  generic  operator/ vehicle  pointing  control  model  was  prepared  for 
analysis  based  on  an  expansion  of  the  Figs.  B-l  and  B-2  models.  A  block 
diagram  of  the  analysis  model  Is  shown  in  Fig.  B-3  which  has  additional 
dynamic  complexity  over  the  simplified  models  of  Figs.  B-l  and  B-2  as 
follows: 


Pilot  lead  generation  to  compensate  for  effective 
vehicle  lag,  Teq,  is  provided  by  angular  rate 
feedback  which  is  assumed  to  represent  a  compos¬ 
ite  of  motion  perception  (i.e. ,  acceleration, 
angular  rotation  and  proprioceptive  sensations). 


Lightly  damped, 
dynamics. 


second-order  lirab/raanipulator 


a  Human  operator  transport  delay  associated  with 
visual  (rv)  and  motion  (rr)  perception. 


System  transport  delays  associated  with  dynamic 


computations  (tc),  display  generation  (x^),  and 
motion  feedback  (xm). 
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Generic  Operator/Vehicle  Tracking  Dynamic  Model 
or  Analyzing  Transport  Delay  Effects 


•  A  low  frequency  trimming  operation  to  minimize 
low  frequency  "hang  off”  errors. 

In  the  Fig.  B-3  analysis  model,  a  disturbance  (5^)  is  added  at  the 
input  to  the  equivalent  vehicle  dynamics  to  represent  the  effects  of 
wind  gusts,  and  roadway  inputs  in  the  case  of  ground  vehicles.  The 
equivalent  vehicle  dynamics  are  represented  by  s  simple  first-order  time 
constant,  Teq,  to  approximate  lags  in  vehicle  rotational  rate  in 
response  to  control  inputs.  Path  lag,  Tg^*  Is  assumed  to  be  zero  for 
this  analysis.  Transport  delay  representations  are  defined  below. 

D.  TRANSPORT  DELAY  SOURCES 

The  model  analysis  was  arranged  to  assess  the  effects  of  three 
sources  of  computational  delay.  The  first  is  a  transport  delay  associ¬ 
ated  with  the  vehicle  dynamics  equations  of  motion  (tc).  This  delay 
could  represent  the  equivalent  delay  used  in  specifying  vehicle  handling 
qualities  (Ref.  B-8)  which  can  result  from  the  composite  effect  of  stick, 
filters,  digital  flight  control  system  delays,  and  control  system  and 
other  high  frequency  vehicle  dynamics  effects.  It  could  also  represent 
the  composite  effect  of  A/D  and  D/A  sampling  holds,  integration  routines 
and  computational  cycle  time.  The  analysis  considered  either  no  delay, 
which  might  correspond  to  an  analog  vehicle  or  an  analog  simulation  com¬ 
puter,  or  a  delay  of  0.075  sec,  which  is  a  common  equivalent  delay  time 
associated  with  complicated  digital  simulation  computations  or  modern 
high  performance  aircraft  with  digital  flight  control  systems. 

The  second  delay  source  considered  was  that  due  to  display  system 
characteristics.  Analysis  conditions  included  either  no  delay,  which 
might  be  associated  with  an  analog  processor,  or  100  msec  delay  which  is 
common  to  many  of  the  current  generation  simulation  CGI  raster  scan 
devices.  The  delay  time  condition  might  also  be  associated  with  the 
camera  servos  on  a  terrain  board  system,  or  digital  processing  in  HUD  or 
EADI  instruments. 

The  final  delay  factor  was  concerned  with  motion  feedback  to  the 
human  operator.  Analysis  conditions  included  no  delay,  or  a  rather  long 
delay  of  250  msec.  The  long-delay  condition  might  be  associated  with  a 


fixed-based  simulator  environment  where  there  were  no  motion  cues  avail¬ 
able,  and  the  human  operator  has  to  generate  heading  rate  cues  visually. 
This  could  also  result  from  motion  lags  in  a  simulator  motion  system 
combined  with  computational  delay  in  generating  the  motion  base  drive 
commands.  The  additional  250  msec  was  calculated  to  give  model  behavior 
that  was  consistent  with  past  measurements  made  under  both  fixed-based 
and  moving  base  conditions  (Ref.  B-9),  and  is  also  consistent  with 
delays  identified  in  flight  simulators  (Ref.  B-10). 

E.  MODEL  PARAMETER  SELECTION 


The  Fig.  B-3  model  has  a  variety  of  parameters  that  must  be  set  to 
represent  either  vehicle  characteristics  or  human  operator  behavior.  A 
nominal  vehicle  heading  time  constant  (T  )  of  about  0.2  sec  was 

ecj 

selected.  This  might  represent  a  light  weight,  high  performance  air¬ 
craft,  or  a  compact  to  intermediate  size  automobile.  The  vehicle  gain 
is  somewhat  arbitrary,  depending  both  on  control  gain  and  vehicle  stab¬ 
ility  derivatives. 

The  human  operator  model  parameters  can  be  divided  into  two  groups; 
those  which  are  relatively  fixed  and  were  assumed  to  be  constant  for 
this  analysis,  and  other  parameters  which  the  human  operator  typically 
adapts  in  order  to  achieve  stable  and  desirable  closed-loop  performance. 
The  trim  constant  (K' )  was  assumed  to  be  constant  at  0.5  rad/sec  which 
is  consistent  with  driver  measurements  discussed  in  Ref.  B-7.  The 
visual  time  delay  (tv)  was  assumed  to  be  constant  at  0.05  sec.  The  time 
delay  associated  with  motion  feedback  perception  (tr)  was  also  set  at 
0.05  sec.  The  second-order  limb/raanipulator  system  dynamics  were  set  at 
a  break  frequency  of  20  rad/sec  and  a  damping  ratio  of  0.5.  The  pure 
delay  and  lag  characteristic  were  set  to  give  a  composite  effective  time 
delay,  with  the  motion  feedback  loop  closed,  of  0.17  seconds  which  is 
consistent  with  past  car-driver  measurements  (Ref.  B-7). 

The  human  operator  can  arbitrarily  adapt  his  inner  and  outer  loop 
gains  (Kr  and  respectively)  and  has  some  control  over  aim  point 
range,  R,  to  optimize  system  performance  and  control  stability.  For  the 
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model  structure  assumed  here,  Kr  was  adjusted  to  obtain  as  wide  a  fre¬ 
quency  response  as  possible  in  the  motion  feedback  loop  while  maintain¬ 
ing  a  reasonable  closed-loop  damping  ratio  (i.e.  ,  Cql  s  0.5).  For  a 
real  vehicle  without  any  computer  delay  or  extra  motion  feedback  delays 
the  variable  Kr  would  be  adjusted  to  cancel  out  the  effects  of  the  vehi¬ 
cle  equivalent  heading  lag,  TeCj.  As  computational  delay  is  added  or  the 
heading  rate  feedback  delay  is  changed,  Kr  would  then  be  adjusted  to 
still  achieve  as  wide  a  bandwidth  as  possible  with  this  inner  loop. 

When  is  properly  adjusted  a  fairly  flat  closed-loop  amplitude 
ratio  can  be  achieved  for  the  motion  feedback  loop  as  illustrated  in 
Fig.  B-4.  When  the  conditions  in  Fig.  B-4  are  achieved  the  closed-loop 
response  of  the  motion  feedback  loop  can  then  be  approximated  by  a  gain 
and  an  equivalent  time  delay  up  to  the  point  where  the  amplitude  ratio 
begins  to  roll  off: 

Motion  Feedback  Closed-Loop  Response  =  Keqe  ° 


Closed-loop  equivalent  parameters  are  given  in  Table  B-l  for  the 
Fig.  B-4  response  functions. 


Note  that  when  there  are  no  extra  computational  delays  and  a  low 
feedback  delay,  as  in  the  upper  lefthand  corner  of  Fig.  B-4,  the  closed- 
loop  bandwidth  of  the  heading  rate  loop  can  be  adjusted  to  be  quite 
high.  Theoretically,  in  this  case  the  bandwidth  is  on  the  order  of 
15  rad/sec,  and  the  equivalent  time  delay  is  quite  small  (about 
120  msec).  If  t0  is  added  to  the  visual  time  delay  (xv),  the  result  is 
an  overall  equivalent  time  delay  for  the  driver  of  about  0.17  sec,  which 
is  consistent  with  measurements  discussed  in  Ref.  B-7.  On  the  other 
hand,  when  a  significant  amount  of  delay  is  put  into  the  motion  feedback 
loop,  as  in  the  lower  rlghthand  corner  of  Fig.  B-4,  the  closed-loop 
bandwidth  of  the  heading  rate  loop  is  reduced  considerably.  In  this 
case  it  is  reduced  to  the  vicinity  of  the  vehicle's  heading  rate  time 
constant  (i.e.,  delayed  feedback  effectively  opens  the  loop).  In  the 
second  case  the  equivalent  time  delay  for  the  heading  rate  loop  is 
Increased  to  about  235  msec. 
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TABLE  B-l.  MOTION  FEEDBACK  LOOP  PARAMETERS  FOR  VARIOUS  LEVELS  OF 
MOTION  FEEDBACK  (-*•„,)  AND  COMPUTATIONAL  (+c)  DELAY 


OPEN  LOOP 

EQUIVALENT  CLOSED 

(sec) 

(sec) 

(sec-1) 

(seS) 

(sec) 

0 

0 

500 

0.414 

0.12 

0.075 

350 

0.331 

0.20 

0.25 

0 

150 

0.175 

0.16 

0.075 

125 

0.150 

0.235 

F.  EQUIVALENT  OPERATOR/VEHICLE  TIME  DELAY  EFFECTS 

The  equivalent  closed-loop  time  delays  that  are  achieved  over  a  wide 
range  of  motion  feedback,  delays  (tm)  and  two  levels  of  computational 
delay  are  illustrated  in  Fig.  B-5.  Here,  note  that  the  computer  com¬ 
putation  delay  (tc)  has  a  much  greater  influence  on  the  equivalent 
closed-loop  delay  than  does  the  motion  feedback  time  delay  which  is 
actually  in  the  feedback  of  this  loop.  These  induced  delays  will  have 
two  effects  on  human  operator/vehicle  performance.  First,  the  increased 
equivalent  closed-loop  time  delay  will  affect  the  operator’s  ability  to 
achieve  an  overall  bandwidth  in  controlling  outer  loop  errors.  Second, 
the  effect  of  disturbances  that  act  on  the  vehicle  will  be  delayed  in 
their  feedback  to  the  operator.  Thus,  there  will  be  an  overall  delay  in 
the  human  operator  responding  to  a  disturbance,  and,  once  the  operator 
responds,  he  will  be  limited  in  the  bandwidth  of  his  response. 

The  parameters  that  remain  to  be  selected  in  the  Fig.  B-3  model 
are  K,j,  and  U0/R.  Procedures  for  optimizing  human  operator  performance 
by  the  selection  of  these  two  variables  has  been  discussed  for  car  driv¬ 
ing  in  Ref.  B-7.  The  procedure  involves  breaking  the  Fig.  B-3  model 
loop  at  the  rc  point  and  then  considering  the  composite  driver/vehicle 
open-loop  transfer  function  proceeding  around  the  loop. 
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Figure  B-5.  Equivalent  Motion  Feedback  Delay 
for  Various  Levels  of  Tm  and  tc 


Given  that  the  inner  loop  closed-loop  dynamics  can  be  interpreted  as 
an  equivalent  time  delay  over  the  outer  loop  bandwidth,  then  an  Extended 
Crossover  Model  describing  function  for  the  Fig,  B-3  model  can  be  writ¬ 
ten  as: 


+  K'  5  +  uo/R  «vTTeS 


YP  YC  =  s  s  s 

Low  Frequency  Low  Frequency  Crossover 

Trimming  Kinematic  Lead  Model 

+  Integration 


The  kinematic  zero  at  U0/R  is  at  low  enough  frequency  that  the  dynamics 
become  K/s-like  in  the  region  of  magnitude  crossover  (the  classical 
crossover  model  law).  Now  the  optimum  K^,  and  U0/R  values  can  be  inter¬ 
preted  in  terms  of  crossover  frequency  and  phase  margin. 

The  Yp*Yc  transfer  function  is  illustrated  in  Fig.  B-6  for  each  com¬ 
bination  of  induced  time  delays  under  consideration.  As  noted  in 
Fig.  B-6,  the  low  frequency  effects  of  aim  point  kinematics  (s  + 
(U0/R))/s  plus  trimming  (s  +  K')/s  have  resulted  in  a  conditionally 
stable  system.  The  variable  U0/R  which  corresponds  to  lead  distance  or 
look-ahead  range  for  the  human  operator’s  aim  point  was  adjusted  to  give 
the  stable  phase  region  indicated  in  Fig.  B-6.  As  can  be  noted,  UQ/R 
was  varied  for  each  combination  of  the  various  time  delays  in  Fig.  B-6 
in  order  to  get  a  similar  stable  phase  region  for  all  conditions.  Once 
this  form  had  been  achieved,  then  the  remaining  variable  was  selected 
in  order  to  give  a  specified  phase  margin.  The  low  frequency  kinematic 
and  trim  effects  cause  a  significant  reduction  in  phase  margin  in  the 
crossover  frequency  region  and  cannot  be  neglected  for  tasks  requiring 
control  to  aim  points  with  speed-to-range  ratios  in  the  region  of  0.1- 
1.0  rad/sec.  It  should  be  noted  that  situations  which  constrain 
thelook  ahead  distance  R  to  small  values  (e.g. ,  driving  in  the  fog, 
pointing  at  shore  range  ground  or  air  targets)  could  decrease  the  region 
over  which  the  phase  is  stable. 

Phase  margin  has  been  used  previously  as  a  metric  for  quantifying 
the  stability  of  car/driver  closed-loop  steering  performance 
(Ref.  B— 11).  is  set  to  achieve  a  desired  phase  margin  at  the  cross¬ 
over  frequency  which  can  be  considered  the  bandwidth  of  the  closed-loop 
operator/vehicle  control  system.  The  phase  margin  quantifies  the  sta¬ 
bility  or  oscillatory  nature  of  the  operator’s  steering  control  behav¬ 
ior.  The  bandwidth  or  crossover  frequency  defines  how  rapidly  the  con¬ 
trol  can  be  carried  out.  For  this  analysis  an  attempt  was  made  to  main¬ 
tain  a  constant  phase  margin  of  30  deg  for  all  cases.  This  level  has 
been  typically  found  in  past  car  driving  studies  (Ref.  B-7).  The 
achievable  crossover  frequency  depends  on  the  total  system  time  delay 
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which  includes  the  inner  loop  equivalent  time  delay,  visual  perceptual 
delay,  and  display  system  transport  delay: 


* 


* 


# 


# 


Te  ~  To  +  Tv  +  Td 


Gain  and  crossover  model  parameters  are  summarized  in  Table  B-2. 
G.  BANDWIDTH  EFFECTS 


The  consequences  of  the  above  adjustment  procedures  can  be  seen  in 
Fig.  B-7.  Here  observe  that  the  control  bandwidth  of  the  operator/ 
vehicle  system  drops  dramatically  as  various  delays  are  added  into  the 
simulation  loop.  Adding  the  0.1  sec  display  delay  has  the  largest  sin¬ 
gle  impact  on  equivalent  time  delay  and  system  bandwidth.  Motion  cue 
delays  had  the  least  impact.  Computational  delays  had  an  effect  some¬ 
where  in  between  motion  cue  delays  and  display  delays.  Perhaps  if  the 
computational  delay  had  been  100  msec  it  would  have  had  a  similar  effect 
to  the  display  delay.  The  concatenation  of  these  various  delay  sources 
deteriorates  the  system  bandwidth  to  an  even  greater  degree.  When  all 
the  delay  sources  were  combined,  the  system  bandwidth  was  cut  by  more 
than  50  percent. 

The  relationship  shown  in  Fig.  B-7  is  a  consequence  of  maintaining  a 
constant  phase  margin.  If  we  had  changed  the  desired  phase  margin,  or 
chosen  a  different  aim  point  range  (thus  changing  the  low  frequency 
kinematic  root  U0/R)  then  a  different  constant  would  have  resulted.  In 
any  case,  we  can  use  the  hyperbolic  relationship  between  o>c  and  xe  to 
determine  how  changes  in  effective  system  time  delay  affect  achievable 
bandwidth.  Assume  that  a  25  percent  decrease  in  system  bandwidth  is 
permissible.  Then 
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TABLE  B-2.  HUMAN  OPERATOR/VEHICLE  GAIN  AND  CROSSOVER  MODEL  PARAMETERS 
FOR  VARIOUS  COMBINATIONS  OF  INDUCED  VEHICLE/SIMULATOR  DELAYS 


VEHICLE/SIMULATOR 

INDUCED  DELAYS 

GAINS 

CROSSOVER  MODEL 
PARAMETERS 

,T«  , 
(sec) 

(sec) 

,Td  . 

(sec) 

U0/R 

(rad/sec) 

(sec  *) 

(rad^sec) 

(sec) 

_  0 

■ 

i 

| 

0 

0 

i 

0.92 

! 

10.26 

4.4 

0.17 

0.1  sec 

0.44 

6.59 

2.8 

0.27 

0.075  sec 

1 

0 

0.50 

i 

8.60 

3.0  ! 

0.25 

0. 1  sec 

6.39 

2.2 

0.345 

0.25  sec 

l 

I 

0 

0 

0.65 

18.51 

3.5 

0.215 

' 

0.1  sec 

0.35 

13.47 

2.5 

i 

: 

j  0.305 

0.075  sec 

0 

0.38 

16.13 

2.6  0.29 

0.1  sec 

| 

0.20 

12.58 

2.0  0.38 
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Motion  Cue  Delay  rm: 

O  =  .00  sec 
A  =  .25  sec 

Computational  Delay  rc: 
Empty  =  0  sec 
Filled  =  .075  sec 

Display  Delay  r<j: 
Untagged  =  0  sec 
Tagged  =  .10  sec 


.2 


Total  System  Equivalent  Time  Delay,  re  (sec) 


Figure  B-7.  System  Bandwidth  as  a  Function 
of  System  Time  Delay 


Thus,  an  increase  of  one  third  in  the  total  effective  system  time  delay 
(fe)  would  be  acceptable.  For  exceptionally  responsive  real  world  sys¬ 
tems,  such  as  cars  which  can  result  in  effective  time  delays  on  the 
order  of  0.17  seconds  (Ref.  B-7),  such  an  incremental  increase  in  time 
delay  due  to  simulator  characteristics,  would  be  on  the  order  of 
50  msec.  (Maximum  time  delays  on  the  order  of  40  msec  have  previously 
been  recommended  for  driving  simulators.  Ref.  B— 12.)  For  sluggish  real 
world  systems  where  effective  system  time  delays  might  be 
0. 3-0.4  seconds,  then  incremental  time  delays  on  the  order  of  100  msec 
might  be  acceptable. 

Regardless  of  the  value  of  the  constant  in  the  Fig.  B-7  relation¬ 
ship,  the  tradeoff  between  system  bandwidth  and  effective  system  time 
d$lay  is  fundamental,  and  gives  some  insight  into  the  consequences  of 
added  computational  delays,  whatever  their  origin. 

H.  PERFORMANCE  EFFECTS 

A  <5^  impulse  disturbance  was  applied  to  the  Fig.  B-3  model  as  indi¬ 
cated  in  order  to  investigate  the  performance  consequences  of  various 
time  delay  sources.  The  impulse  input  might  be  attributable  to  a  wind 
gust  or  road  input  in  the  case  of  ground  vehicles.  Time  histories  of 
the  model  transient  response  to  an  impulse  disturbance  input  are  illus¬ 
trated  in  Fig.  B-8  for  an  automobile  traveling  at  UQ  =  80  ft/sec 
(55  raph).  For  the  low  frequency  kinematic  characteristics  given  in 
Table  B-2  (U0/R  =  0.2-0.92)  the  Fig.  B-8  transients  could  also  be  scaled 
to  represent  airplane  motions  in  the  Fig.  B-l  model  (e.g.  ,  at  800  ft/sec 
this  would  represent  target  ranges  of  roughly  900-4000  ft). 

The  effects  of  the  various  transport  delays  on  system  performance 
are  quite  evident  in  Fig.  B-8.  Note  that  the  model's  ability  to  main¬ 
tain  lane  position  deteriorates  radically  as  the  amount  of  simulator 
delay  is  increased.  The  effect  of  the  various  delay  sources  are 
directly  observable  in  the  steering  wheel  response  of  the  model  driver. 
As  the  delay  sources  are  concatenated,  the  model  driver  takes  longer  and 
longer  to  initially  respond  to  the  Input  disturbance.  This  is  consis¬ 
tent  with  the  data  given  in  Table  B-2  which  shows  the  total  effective 
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Figure  B-8.  Driver/Vehicle  System  Closed-Loop  Response  to  an  Impulse  Disturbance 


system  time  delay  increasing  from  a  no  delay  level  of  0.17  seconds  to 
0.38  seconds  in  the  worst  delay  case. 

The  cycle  time  of  the  system  transient  response  also  obviously 
increases  with  increasing  delay  sources  in  Fig.  B-8.  This  effect  is 
consistent  with  the  decreasing  bandwidth  as  a  function  of  time  delay 
shown  in  Fig.  B-7.  Because  of  the  driver/vehicle  system's  increasingly 
delayed  regulatory  response  to  the  transient  innnt,  the  maximum  vehicle 
heading  deviation  nearly  doubles  in  the  worst  delay  case  compared  to  the 
no  delay  condition,  and  the  lane  deviation  increases  by  more  than  a  fac¬ 
tor  of  three  with  the  increasing  delay.  Note  also  that  each  of  the 
delay  components  considered  separately  in  Fig.  B-8  have  a  similar  effect 
on  system  performance,  as  does  the  concatenation  of  any  two  delay 
sources. 

I.  SYSTEM  ARCHITECTURE  AND  DELAY  COMPENSATION 

The  effective  system  delays  analyzed  herein  can  arise  from  a  variety 
of  sources.  Effective  computational  delays  are  due  to  a  composite  of 
A/D  and  D/A  operations,  computational  algorithms  (e.g. ,  integration  rou¬ 
tines)  and  general  software  architecture.  Cycle  time  may  not  be  a  true 
measure  of  effective  delay  if  some  routines  are  updated  more  often  than 
others  (e.g.,  high  frequency  modes  might  be  updated  more  rapidly  than 
kinematic  integrations).  Motion  drive  computations  can  have  analogous 
considerations,  and  the  frequency  response  of  the  drive  servos  must  also 
be  accounted  for.  CGI  systems  must  maintain  high  refresh  and  update 
rates  to  portray  smooth  motion  (i.e.  ,  typically  50  Hz  or  above),  but 
multiple  frame  times  may  be  required  for  angular  and  translational  com¬ 
mands  work  their  way  through  typical  pipeline  architectures. 

Delay  compensation  can  be  considered  at  various  stages  in  the  system 
architecture.  Minimum  delay  integration  routines  should  be  considered 
for  dynamic  computations  (Ref.  B— 13).  The  update  of  motion  and  angular 
orientation  cues  are  more  critical  to  closed-loop  operator/vehicle  sys¬ 
tem  response  than  outer  loop  translational  information  that  is  already 
delayed  by  kinematic  Integration.  Thus  in  computing  equations  of 
motion,  angular  rates  and  orientation,  and  accelerations  could  be 


updated  more  rapidly  than  inertial  velocity  and  position.  In  CGI  dis¬ 
play  systems,  angular  transformations  could  be  updated  more  rapidly  than 
perspective  transformations. 

Lead  or  rate  compensation  might  be  considered  for  both  host  computer 
and  CGI  computations.  Overall  system  dynamics  should  be  considered 
here,  however.  The  transfer  functions  in  Figs.  B-4  and  B-6  suggest  that 
for  systems  with  adequate  motion  cues,  lead  frequencies  in  the  region  of 
the  human  operators  limb/manipulator  bandwidth  (>  10  rad/sec)  might  be 
acceptable,  while  in  the  case  of  delayed  or  no  motion  cues,  lead  compen¬ 
sation  could  be  Increased  to  cover  the  bandwidth  above  the  basic  vehicle 
dynamics  bandwidth.  In  general  lead  frequency  must  be  above  system 
crossover  frequency  ( u>c)  in  order  to  avoid  compromising  system  gain  mar¬ 
gin. 

J.  CONCLUDING  REMARKS 

The  model  analysis  herein  shows  that  the  effects  of  several  computa¬ 
tional  delay  sources  in  manual  vehicle  control  systems  can  be  evaluated 
to  a  first  approximation  by  their  effect  on  a  composite  effective  sys¬ 
tem  time  delay.  This  effective  time  delay  constrains  the  closed-loop 
bandwidth  that  can  be  achieved  by  the  human  operators.  Tolerable  compu¬ 
tational  delays  can  be  determined  by  specifying  a  permissable  system 
bandwidth  reduction.  The  model  analysis  also  shows  that  degradation  in 
performance,  such  as  regulation  against  transient  disturbance,  is  con¬ 
sistent  with  system  bandwidth  reduction. 

In  general,  compensation  for  effective  system  delays  must  be  consid¬ 
ered  in  an  overall  system  context.  System  delays  and  compensation 
effects  should  be  measured  with  input/output  identification  procedures 
using  appropriate  system  inputs  and  sensors  to  measure  outputs  (e.g. , 
gyros  and  accelerometers  to  measure  platform  motions  and  photo  detectors 
to  measure  display  system  response).  Response  functions  should  be  com¬ 
pensated  to  approach  the  less  delayed  response  of  the  ideal  target  sys¬ 
tem.  Finally,  the  fidelity  of  the  system  response  should  be  considered 
from  the  human  operator’s  point  of  view.  In  moving  base  systems,  visual 
and  motion  cues  should  be  consistent,  and  in  general  perceived  vehicle 


■$® 


response  should  be  consistent  with  the  operator's  expectations.  The 
analytic  consequences  of  these  fidelity  considerations  are  not  well 
understood,  and  typically  would  require  final  empirical  tuneup. 
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A  FAST,  PROGRAMMABLE,  LOW-COST  DISPLAY  DEVICE 
FOR  MAN-IN-THE-LOOP  SIMULATION 


A.  OVERVIEW 

Throughput  delays  In  man-in-the-loop  simulation  can  cause  degraded 
performance  and  lead  to  potentially  unstable  operation.  Current  CGI 
approaches  generally  have  significant  computational  delays,  and  in  addi¬ 
tion  involve  a  costly  combination  of  a  general  purpose  host  computer  and 
special  purpose  digital  display  processors.  This  appendix  describes  a 
microprocessor  based  calligraphic  display  system  which  includes  an  ana¬ 
log  processor  for  accomplishing  rotational  and  perspective  transforma¬ 
tions.  The  system  permits  defining  a  complete  data  base  which  can  be 
rapidly  mapped  into  instrument  formats  and  a  perspective  plane  for  pre¬ 
senting  out-the-window  scenes  for  low-cost,  vehicle  control  simulations. 

B.  INTRODUCTION 

Visual  display  throughput  delays  can  seriously  degrade  man-in-the- 
loop  simulation  performance  (Refs.  C-L  and  C-2).  In  controlling  respon¬ 
sive  vehicles  such  as  automobiles  and  high  performance  aircraft,  the 
human  operator  represents  a  transport  delay  on  the  order  250  msec  or 
less.  Simulator  feedback  devices  such  as  display  systems  should  not 
significantly  increase  the  total  amount  of  closed  loop  transport  delay 
in  order  to  permit  adequate  performance  and  avoid  stability  problems 
(Ref.  C-3). 

The  display  approach  described  herein  was  developed  as  part  of  a 
low-cost  simulator  technology  program,  to  provide  a  relatively  high 
update  rate  calligraphic  scene  generator.  It  was  designed  around  a 
microprocessor-based  waveform  generator  in  order  to  permit  storage  of 
complex,  programmable  three-dimensional  data  bases.  An  analog  processor 
was  designed  to  accomplish  angular  and  perspective  transformations  in 
order  to  minimize  cost  and  throughput  delays.  The  basic  digital  wave 


wc  =  Operator/ Vehicle  Bandwidth 

re  =  Effective  Time  Delay  (operator  +  vehicle  +  computation) 
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Figure  C-l.  Generic  Model  of  a  Human  Operator/Vehicle  Control 
Task  to  Illustrate  the  Effect  of  Computational  Delays 


form  generator  approach  has  previously  been  described  (Ref.  C-4).  This 
appendix  describes  the  throughput  delay  problem,  and  the  architecture  of 
a  display  system  which  provides  a  low-cost  solution. 

C.  COMPUTATIONAL  DELAY  PROBLEM 

A  block  diagram  for  a  generic  human  operator/vehicle  control  task  is 
Illustrated  in  Fig.  C-l.  This  simplified  Laplace  Transform  dynamic 
model  could  represent  a  driver/car  scenario  (Ref.  C-5)  or  a  pilot/ 
airplane  control  task  (Ref.  C-6).  A  "crossover"  model  form  is  used  to 
approximate  the  combined  response  of  the  human  operator  and  vehicle 
angular  motion  (Ref.  C-7),  which  includes  a  gain,  u>c,  and  an  equivalent 
time  delay,  Te.  Aside  from  kinematic  integrations,  some  extra  dynamics 
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are  provided  for  the  vehicle's  path  response.  These  dynamics  are  usu¬ 
ally  negligable  for  cars,  and  for  airplanes  amount  to  an  equivalent 
first-order  lag. 

A  simple  control  system  stability  criterion,  termed  phase  margin, 
can  be  derived  as  indicated  in  Fig.  C-l  (Ref.  C-5).  The  system  is  sta¬ 
ble  for  positive  values  of  but  becomes  more  oscillatory  the  smaller 
<t>\j  gets.  Note  that  <j)^j  decreases  in  direct  proportion  to  the  equivalent 
time  delay,  Te,  of  the  driver/ vehicle  crossover  characteristic.  Thus, 
in  a  simulator,  extra  computational  delays  in  vehicle  dynamics  and  dis¬ 
play  systems  directly  affect  stability. 

It  can  be  shown  that  delays  in  computing  and/or  displaying  vehicle 
position  do  not  affect  stability  as  much  as  the  Te  delays.  Extra  delays 
in  xe  affect  the  feedback  of  vehicle  attitude  which  the  human  operator 
senses  almost  immediately  after  control  inputs.  The  vehicle  position 
loop  includes  an  additional  integration,  however,  which  makes  feedback 
in  this  loop  slow.  Therefore  time  delays  have  relatively  less  influence 
on  position  changes  than  on  attitude  changes  (Ref.  C-8).  This  result 
has  implications  for  display  processor  design,  and  suggests  that  delays 
in  the  angular  orientation  transformations  should  be  minimized.  The 
architecture  for  the  processor  described  herein  was  designed  from  this 
point  of  view. 

D.  DISPLAY  PROCESSOR  DESIGN 

The  display  system  consists  of  two  major  elements:  1)  a  digital 
waveform  generator  which  draws  three-dimensional  (rectangular  coordi¬ 
nate)  maps  relative  to  observer  position  from  memory  stored  coordinates; 
2)  an  analog  transformation  system  which  provides  angular  transforma¬ 
tions  for  orienting  the  observer's  line  of  sight  and  a  perspective 
transformation  for  drawing  images  within  the  observer's  field  of  view  on 
the  display  plane.  The  system  architecture  and  software  control  is  set 
up  to  accommodate  instrument  display  formats  which  may  require  roll 
and/or  pitch  or  no  transformation,  horizon  scenes  which  require  angular 
transformation  but  no  perspective,  and  out-the-window  scenes  requiring 
all  transformations. 
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A  block  diagram  of  the  overall  processor  system  is  shown  in 
Fig.  C-2.  The  digital  waveform  generator  consists  of  a  single  multibus 
card  which  contains  a  Z80  microprocessor,  64K  bytes  of  memory  (an  arbi¬ 
trary  mix  of  RAM  and  ROM),  and  hybrid  circuitry.  This  card  generates  x, 
y,  and  z  axis  analog  waveforms,  associated  blanking  pulses  and  an  inten¬ 
sity  control  waveform,  plus  an  attribute  code  which  selects  the  trans¬ 
formations  that  will  be  applied  to  a  given  set  of  imagery.  An 
Intel  8086  single  board  computer  serves  as  the  system  host  processor, 
and  communicates  with  the  Z80  card  over  the  multibus  through  a  shared 
memory  scheme. 

The  8086  can  write  directly  into  the  shared  Z80  memory  space  to 
cause  different  sets  of  imagery  to  be  displayed  and  to  update  the 
observer's  viewing  position  (x,  y,  z  coordinates)  within  the  three- 
dimensional  map.  Memory  conflicts  are  arbitrated  by  a  hardware  bus 
lockout  when  the  Z30  is  reading,  and  by  a  shared  software  semaphore  flag 
which  the  8086  uses  when  it  writes  address  data  into  Z80  RAM.  The  com¬ 
putational  load  on  the  Z80  is  minimal,  consisting  of  memory  fetch  and  a 
fixed  point  add  to  update  the  observer  position  for  each  vector  and 
point.  Thus  the  vector  rate  of  the  processor  is  relatively  high,  run¬ 
ning  about  8000  vectors  per  second.  At  a  50  Hz  update  rate  to  minimize 
flicker,  display  scenes  with  about  160  vectors  can  be  nominally  pre¬ 
sented.  (For  future  upgrades,  a  faster  16  bit  processor  would  allow 
more  vectors  and  finer  resolution. ) 

The  digital  waveform  generator  sends  x,  y,  z,  and  intensity  signals 
in  the  form  of  a  three-dimensional  vector  to  an  analog  transformation 
processor,  which  consists  of  angular  and  perspective  transformation  cir¬ 
cuitry  as  indicated  in  Fig.  C-2.  The  angular  transformations  are  per¬ 
formed  by  a  direction  cosine  matrix.  The  direction  cosine  matrix  is 
computed  by  six  degree-of-f reedom  vehicle  equations  of  motion  in  the 
8086  host  processor  using  quaternions.  The  host  processor  card  includes 
an  8087  hardware  math  coprocessor  for  maximum  computational  speed.  The 
direction  cosine  matrix  is  then  D/A  converted  and  sent  to  the  analog 
angular  transformation  processor  as  analog  voltages.  This  approach 
means  that  angular  motions  exhibit  minimal  display  processor  delay. 
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Figure  C-2.  Computer/Processor  Architecture 
for  Calligraphic  Display  System 


E.  CONCLUDING  REMARKS 

Small  angular  motion  delays  are  an  important  feature  of  the  display 
system  described  here  for  application  to  vehicle  control  simulations. 
Since  the  human  operator’s  highest  control  bandwidth  requirements  are  in 
attitude  control,  this  control  would  be  most  degraded  by  computational 
delay.  Another  powerful  feature  of  this  approach  to  display  generation 
is  that  each  vector  is  separately  encoded  for  the  types  of  transforma¬ 
tions  to  be  applied  to  it  by  the  transformation  hardware.  As  noted  in 
the  Fig.  C-2  block  diagram,  the  Z80  microprocessor  sends  a  transforma¬ 
tion  attribute  code  with  each  vector.  The  attribute  code  is  then  used 
by  the  transformation  processor  to  determine  which  of  several  sets  of 
transformations  will  be  applied  to  the  vectors.  For  example,  this 
approach  allows  generation  of  HUD  (Head-Up  Display)  pitch  scales  which 
only  require  roll  transformation,  airplane  referenced  vectors  (e.g.  ,  gun 
tracers)  which  only  go  through  the  perspective  transformation,  and  per¬ 
haps  other  HUD  symbology  that  doesn’t  require  any  transformation  at  all. 
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Photos  of  several  display  configurations  are  shown  in  Fig.  C-3. 
This  graphics  approach  allows  for  relatively  complex  programmable  scene 
generation  with  low  computational  delays.  The  hardware  is  inherently 
low-cost,  and  allows  for  additional  future  expansion  of  capabilities. 
This  type  of  calligraphic  system  could  potentially  provide  for  curved 
vectors  (not  just  straight  line  approximations)  through  additional  ana¬ 
log  transformation  (see  Ref.  C-9)  and  could  also  include  some  limited 
fill  capability  by  high  frequency  modulation  of  the  vectors. 
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Figure  C-3.  Calligraphic  Display  Scenes  Including 
Horizon,  Ground  Grid,  and  IIUD  Pitch  Scale 
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